[regext] Fwd: New Version Notification for draft-ietf-regext-epp-fees-00.txt

[Gavin Brown]

Dear colleagues,

I have republished draft-brown-epp-fees-07 as
draft-ietf-regext-epp-fees-00 (so farewell then, "the brown extension").
The intention is to publish an -01 draft with the "option C" changes
discussed previously.

Regards,

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.
--- Begin Message ---

A new version of I-D, draft-ietf-regext-epp-fees-00.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:   draft-ietf-regext-epp-fees
Revision:   00
Title:  Registry Fee Extension for the Extensible Provisioning Protocol 
(EPP)
Document date:  2016-06-28
Group:  regext
Pages:  37
URL:
https://www.ietf.org/internet-drafts/draft-ietf-regext-epp-fees-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/
Htmlized:   https://tools.ietf.org/html/draft-ietf-regext-epp-fees-00


Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for registry fees.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--- End Message ---


signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] TLD Phase Discovery

[Gavin Brown]

On 14/08/2017 19:27, Gould, James wrote:

> As a co-author of Launch Phase Mapping going back 5 years and the one that 
> added the “Domain names may be made available only in unique launch phases, 
> whilst remaining unavailable for concurrent launch phases” language to the 
> draft, I’m aware of the intent.  Wil and Gavin can also weigh in on the 
> intent.  The intent was for the launch phases to be associated with the TLD 
> (or zone), where there may be a policy for launch phases that differentiates 
> the availability of domain names.  It was never intended or foreseen that a 
> launch phase would be used to group a set of domain names as a form of fee 
> classification.  We can agree to disagree on this topic. 

I agree with Jim. The Launch Phase was not designed to deal with premium
names: I would not have created the fee extension if it were.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gavin Brown]

+1.

On 11/06/2018 14:49, Patrick Mevzek wrote:
> On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
>> [SAH] Jim, keep in mind that the security guidelines you mentioned are 
>> just that – *guidelines* published by a particular entity that may or 
>> may not be appropriate for use in different operating environments. I’d 
>> be inclined to loosen the Schema to conform to other possibilities and 
>> include an informational reference with text along the lines of “Servers 
>> SHOULD enforce minimum and maximum password length requirements that are 
>> appropriate for their operating environment. One example of a guideline 
>> for password length policies can be found in  [reference 
>> here]”. A minimum length of 1 would ensure that the field can’t be 
>> blank, and the server can check if whatever is provided lines up with 
>> expectations for clients.
> 
> That sound perfect to me. Thanks Scott for the text.
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Provider status? (Problems with IP network requests)

[Gavin Brown]

Hi Adam (and the list),

Since my last email, I've updated rdap.org so that it uses the bootstrap
registries. So a query to https://rdap.org/{domain,ip,autnum}/{handle}
will redirect to the correct RDAP service (as long as that service is in
the bootstrap files).

Once the object tag registry is up, I'll add support for that too.

Please (everyone) feel free to test, try to break, etc. Drop me a line
with any feedback.

G.

On 16/05/2018 22:04, Gavin Brown wrote:
> Hi Adam,
> 
> I run rdap.org (in a personal capacity). Unfortunately it has not
> received the attention it needs: it does not consume the IANA bootstrap
> file, so its map of prefixes to RIRs may not be complete. My apologies.
> 
> If you're writing a client implementation I suggest you consume the
> bootstrap file directly, as per RFC 7484.
> 
> Gavin.
> 
> On 16/05/2018 13:24, Adam Shannon wrote:
>> Hi all,
>>
>> I'm working on a client implementation of RDAP and running into some
>> problems.
>>
>> Are all IPv4 ranges covered? It doesn't appear so, and servers from
>> about.rdap.org <http://about.rdap.org> don't seem to be responding to
>> domains they're said to serve.
>>
>> $ curl -L -v -H "Accept: application/json" https://rdap.org/ip/$(dig
>> +short code.jobs <http://code.jobs>) 
>> ...
>>> GET /ip/45.56.121.172 <http://45.56.121.172> HTTP/2
>>> Host: rdap.org <http://rdap.org>
>>> Accept: application/json
>>
>> < content-type: application/rdap_error+json
>>
>> {"errorCode":404,"title":"No RDAP service could be found for
>> '45.56.121.172'"}
>>
>> Also, I tried another example and am seeing a different response format
>> than what I saw in the RFC's.
>>
>> $ curl -L -v -H "Accept: application/json" https://rdap.org/ip/192.0.2.0
>> {
>>     "net": {
>>     // ...
>>     "registrationDate": {
>>     "$": "2009-06-29T11:15:30-04:00"
>>     },
>>     "ref": {
>>     "$": "https://whois.arin.net/rest/net/NET-192-0-2-0-1;
>>     },
>>     "endAddress": {
>>     "$": "192.0.2.255"
>>     },
>>     "handle": {
>>     "$": "NET-192-0-2-0-1"
>>     },
>>     // ...
>>     "version": {
>>     "$": "4"
>>     }
>>     }
>> }
>>
>>
>> ___
>> regext mailing list
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
>>
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-brown-whoami-00.txt

[Gavin Brown]

Hi Patrick, apologies for the delay in responding.

On 20/12/2017 22:25, Patrick Mevzek wrote:
> 
> 
> On 20/12/2017 12:08, Gavin Brown wrote:
>> Having thought about this topic for a little while, it occurred to me
>> that there might be some benefit in a "straw man" proposal for how
>> centralised databases of registration data might be avoided. So I wrote
>> this Internet-Draft which describes a simple decentralised alternative
>> to Whois/RDAP directories.
>>
>> Obviously it is far from a perfect solution, but I have yet to think of
>> any criticism of it that does not equally to Whois/RDAP as they
>> currently exist. So I have published my draft for feedback.
> 
> What do you do for domain names that are registered but not technically
> used, meaning no delegation in DNS?
> In that case you can not publish URI records in their zone (except if
> there is a way to have the registry publish it instead in its zone, like
> it does for glues), nor having a webserver reply for the website under
> this domain.

The registry could publish the URI record, but I think this is not the
best option.

WHOAMI is not a complete replacement for WHOIS; because it cannot
provide the technical metadata about the domain (ie creation date,
expiry date, sponsoring registrar, etc). So a registry which allows its
registrants to deploy WHOAMI will still need a "thin" WHOIS or RDAP service.

In this situation, a client which wants to look up a suspended domain
can use the nameservers (and glue if any) provided by the parent
registry's WHOIS/RDAP service and query them directly for the URI (or
the address records of the web server when falling back to the
well-known URL).

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] draft-ietf-eppext-idnmap: extending the response

[Gavin Brown]

Hi Francisco,

I came across an edge case that I think could be resolved with a change
to the idnmap extension, to extend the  response.

It involved a domain that was syntactically valid in both Chinese and
Japanese, but was not available for registration in Chinese as a variant
domain was already registered.

The server returned a  element in the 
response, because the domain was available to register in Japanese.

However, the client submitted a  command with the "zh" in the
 element, and the server rejected the command.

Had the client submitted the  command with "ja" in the
 element (or had it omitted the  element
altogether) then the command would have succeeded.

In this situation, it would be useful for the server to be able to tell
the client what IDN tables a domain is valid in, so the client can
submit the right table in the  command. Here's a possible syntax
for this:

S: 
S:   
S: 
S:   xn--espaol-zwa.example.com
S:   
S: latn
S: es
S:   
S: 
S:   
S: 

What do you think?

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Contact Mapping for RDAP

[Gavin Brown]

This was published earlier today:

https://tools.ietf.org/html/draft-stepanek-jscontact-00

Abstract

   This specification defines a data model and JSON representation of
   contact information that can be used for data storage and exchange in
   address book or directory applications.  It aims to be an alternative
   to the vCard data format and to be unambiguous, extendable and simple
   to process.  In contrast to the JSON-based jCard format, it is not a
   direct mapping from the vCard data model and expands semantics where
   appropriate.

On 22/02/2019 13:41, Gavin Brown wrote:
> Thanks Andy, Mario and Bernhard for the useful feedback.
> 
> It seems to me that there is a lot of appetite for a way to replace
> jCard: in addition to F2F conversations and discussions in the ICANN
> world, I've also had private feedback on this draft which indicates a
> lot of frustration with jCard from implementers.
> 
> If anyone implementing an RDAP client or server has some experiences
> with jCard that they can share that would be very helpful in
> understanding the demand for an alternative.
> 
> jCard was added in draft-ietf-weirds-json-response-03, so the last
> version to have "native" contacts was -02.
> 
> In it, entities in DNRs had a different syntax to entities in RIRs,
> however, there was a lot of similarity. Adding jCard helped in that the
> contact information got moved into a subordinate object property rather
> than being mixed in with the metadata (handle, roles, links, etc).
> 
> You can use the syntax for the contact info in the -02 draft and replace
> the "eppContactInfo" object in my draft with a generic "contactInfo"
> object such as the following:
> 
> {
>   "objectClassName": "entity",
>   "handle": "",
> 
>   "contactInfo": {
> "entityNames": [
>   "Joe Bob, Inc.",
>   "Bobby Joe Shopping"
> ],
> "postalAddress": [
>   "123 Maple Ave",
>   "Suite 90001",
>   "Vancouver",
>   "BC",
>   "12393"
> ],
> "emails": [
>   "j...@bob.com",
>   "b...@joe.com"
> ],
> "phones": {
>   "office": [
> "1-958-555-4321",
> "1-958-555-4322"
>   ],
>   "fax": [
> "1-958-555-4323"
>   ],
>   "mobile": [
> "1-958-555-4324"
>   ]
> }
>   },
> 
>   // rest of metadata
> }
> 
> G.
> 
> On 19/02/2019 11:23, Andy Newton wrote:
>> On Tue, Feb 19, 2019 at 08:05:50AM +0100, Mario Loffredo wrote:
>>> Hi Gavin,
>>>
>>> if I understand correctly, this extension involves only those RDAP entities
>>> in common with EPP (i.e registrant, admin, tech, billing), doesn't it?
>>>
>>> If so, what about the other entities (e.g. registrar, reseller) ? Should
>>> they be represented by jCard ?
>>
>> I have the same question and concern. While I support moving away
>> from jCard, we should not be focusing only on EPP especially since RDAP was
>> first widely adopted and is used today by non-EPP communities. RDAP itself is
>> not a product of the EPP community but was an outgrowth of experiments
>> conducted by the RIRs.
>>
>> That said, being compatible with EPP is certainly a requirement in my 
>> opinion.
>>
>> Given this is a rather substantial change, we should also be thorough in our
>> approach:
>>
>>   1. We should dig up the pre-jCard RDAP drafts and see if there is good 
>> stuff
>> there.
>>   2. We should either consult or repeat the work of CN-NIC during the WEIRDS
>> working group where they study the Whois output of all available registries 
>> and
>> found what was needed.
>>   3. We should also pay attention to the discussions around contacts in JMAP
>> now going on in the IETF.
>>
>> Overall, what is specified here looks good to me. Here are my comments for
>> improvements:
>>
>>   1. The country and region codes should be tied to ISO-3166 or a superset.
>>   2. There should be a place to spell out both region and country. Some
>> registries do not collect 3166 codes.
>>   3. Phone, fax, email should be arrays because some registries collect
>> multiples of these.
>>   4. There should be an indicator noting that the contact information is for 
>> an
>> individual.
>>
>> -andy
>>
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Contact Mapping for RDAP

[Gavin Brown]

Thanks Andy, Mario and Bernhard for the useful feedback.

It seems to me that there is a lot of appetite for a way to replace
jCard: in addition to F2F conversations and discussions in the ICANN
world, I've also had private feedback on this draft which indicates a
lot of frustration with jCard from implementers.

If anyone implementing an RDAP client or server has some experiences
with jCard that they can share that would be very helpful in
understanding the demand for an alternative.

jCard was added in draft-ietf-weirds-json-response-03, so the last
version to have "native" contacts was -02.

In it, entities in DNRs had a different syntax to entities in RIRs,
however, there was a lot of similarity. Adding jCard helped in that the
contact information got moved into a subordinate object property rather
than being mixed in with the metadata (handle, roles, links, etc).

You can use the syntax for the contact info in the -02 draft and replace
the "eppContactInfo" object in my draft with a generic "contactInfo"
object such as the following:

{
  "objectClassName": "entity",
  "handle": "",

  "contactInfo": {
"entityNames": [
  "Joe Bob, Inc.",
  "Bobby Joe Shopping"
],
"postalAddress": [
  "123 Maple Ave",
  "Suite 90001",
  "Vancouver",
  "BC",
  "12393"
],
"emails": [
  "j...@bob.com",
  "b...@joe.com"
],
"phones": {
  "office": [
"1-958-555-4321",
"1-958-555-4322"
  ],
  "fax": [
"1-958-555-4323"
  ],
  "mobile": [
"1-958-555-4324"
  ]
}
  },

  // rest of metadata
}

G.

On 19/02/2019 11:23, Andy Newton wrote:
> On Tue, Feb 19, 2019 at 08:05:50AM +0100, Mario Loffredo wrote:
>> Hi Gavin,
>>
>> if I understand correctly, this extension involves only those RDAP entities
>> in common with EPP (i.e registrant, admin, tech, billing), doesn't it?
>>
>> If so, what about the other entities (e.g. registrar, reseller) ? Should
>> they be represented by jCard ?
> 
> I have the same question and concern. While I support moving away
> from jCard, we should not be focusing only on EPP especially since RDAP was
> first widely adopted and is used today by non-EPP communities. RDAP itself is
> not a product of the EPP community but was an outgrowth of experiments
> conducted by the RIRs.
> 
> That said, being compatible with EPP is certainly a requirement in my opinion.
> 
> Given this is a rather substantial change, we should also be thorough in our
> approach:
> 
>   1. We should dig up the pre-jCard RDAP drafts and see if there is good stuff
> there.
>   2. We should either consult or repeat the work of CN-NIC during the WEIRDS
> working group where they study the Whois output of all available registries 
> and
> found what was needed.
>   3. We should also pay attention to the discussions around contacts in JMAP
> now going on in the IETF.
> 
> Overall, what is specified here looks good to me. Here are my comments for
> improvements:
> 
>   1. The country and region codes should be tied to ISO-3166 or a superset.
>   2. There should be a place to spell out both region and country. Some
> registries do not collect 3166 codes.
>   3. Phone, fax, email should be arrays because some registries collect
> multiples of these.
>   4. There should be an indicator noting that the contact information is for 
> an
> individual.
> 
> -andy
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [gtld-tech] EPDP recommendations and EPP

[Gavin Brown]

On 01/03/2019 15:03, Patrick Mevzek wrote:
> [snip] 
>
> Instead of updating RFC5733 I would suggest creating a new object,
> a "light (or shallow) contact" which is like a contact currently, just with 
> less fields.
> Domains could use "full contacts" (the ones we know today) or light contacts 
> (the new 
> ones).

I can't see how this would work. Let's say we define a new object
mapping for "light" contacts, with its own namespace, to be used with
just the  element in domain objects.

Could such contacts be used with domains without an update to RFC 5731?

Could a registrar determine whether a given contact object was a "full"
contact or a "light" without performing an  command?

I think this would cause a huge amount of confusion and pain.

Furthermore, my research[1] indicates that the "one-to-many"
relationship between domains and contacts that is implicit in EPP does
not reflect reality, so defining a new "first class" EPP object just
perpetuates the data management issues that registries currently have to
deal with.

If we're going to write a new RFC just for technical contacts then I
would suggest that it should define an extension to the domain object,
since that is (a) simpler for clients and servers to implement and (b)
more accurately maps to the way the data is represented and handled
outside of EPP.

> One has to keep remembering that EPP is not just used by gTLDs, so any change 
> has to
> be done in such a way that it does not impact negatively any operation done 
> outside
> of ICANN circles.

It seems to me that updating RFC5733 would have a bigger impact outside
the gTLD world than either of the other options I've proposed:
presumably many ccTLD registries rely on the the XML schema in RFC 5733
to enforce their data collection policies, but if we change that schema,
and they unknowingly update their implementation, then their data
collection policy will be changed without them knowingly accepting it.

G.

[1]:
http://regiops.net/wp-content/uploads/2017/05/ROW6_Brown_Contact-Object-Management-by-Registrars.pdf

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Security Lock anyone? (Was: Preliminary agenda for Prague, and call for agenda items)

[Gavin Brown]

If a BoF happens in Prague I will certainly attend.

On 25/02/2019 07:26, Alexander Mayrhofer wrote:
> Antoin, all,
> 
>  
> 
> for now this is more a question / request to the group, rather than a
> specific agenda slot request – but:
> 
>  
> 
> In the light of the recent attacks on registration interfaces, do we
> want to take a fresh look at standardization of “Registry Lock” /
> “Security Lock”. There’s some previous work on this topic (see
> https://tools.ietf.org/html/draft-wallstrom-epp-registrant-problem-statement-00).
> As Patrick pointed out, there’s also some IPR considerations in this
> area (See his blog post at
> http://www.circleid.com/posts/20150603_registry_lock_or_epp_with_two_factor_authentication/).
> 
>  
> 
> I constantly hear from registrars that “Security Lock” (our product
> name) would be much more attractive if there wasn’t a myriad of
> different processes at each registry – so my take is that there’s room
> for standardization (which probably goes beyond the pure EPP extension).
>  I’m also hearing some fellow ccTLD colleages are interesting in a
> common “profile”.
> 
> Would regext be the right spot for such a discussion? If yes, would it
> be interesting to hold a 20 minutes slot in Prague? Or even a Bar-BoF
> before we “report back” to the working group?
> 
>  
> 
> Best,
> 
> Alex
> 
>  
> 
>  
> 
> *Von:*regext  *Im Auftrag von *Antoin Verschuren
> *Gesendet:* Sonntag, 24. Februar 2019 14:43
> *An:* Registration Protocols Extensions 
> *Betreff:* [regext] Preliminary agenda for Prague, and call for agenda items
> 
>  
> 
> Hi all,
> 
> Please find the preliminary agenda for Prague attached.
> I hope I captured everyone that has requested time to speak. If not, let
> the chairs know.
> We still have a little bit of time left on the agenda, so if you have
> urgent agenda items, let us know as well.
> If you are on the agenda, start preparing ;-)
> 
> 
> 
> 
> Regards, Jim and Antoin
> 
> - -- 
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
> 
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] EPP Contact Mapping for RDAP

[Gavin Brown]

After some private discussions, I've come up with a rough draft of a
document specifying an alternative representation of contact data for
RDAP entities that does away with vCard, and uses the model from EPP
instead:

https://tools.ietf.org/html/draft-brown-epp-contacts-in-rdap-00

For your consideration.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-partial-response

[Gavin Brown]

I support adoption of this document.

On 18/01/2019 16:03, Antoin Verschuren wrote:
> Hi all,
> 
> As discussed on the mailinglist, we have selected 5 documents that people 
> most want to be added to our milestone list.
> To be able to to that the documents should first be adopted as working group 
> documents.
> This is a formal adoption request for 
> draft-loffredo-regext-rdap-partial-response
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT, and comment to the list, clearly stating your view.
> Please also indicate if you are willing to contribute text, review, be a 
> document shepherd, etc.
> 
> This call for adoption ends 25 Januari 2019.
> If there are no objections, and we receive enough consensus for adoption, the 
> chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Jim and Antoin.
> 
> - -- 
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
> 
> 
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

[Gavin Brown]

I support adoption of this document.

On 18/01/2019 16:04, Antoin Verschuren wrote:
> Hi all,
> 
> As discussed on the mailinglist, we have selected 5 documents that people 
> most want to be added to our milestone list.
> To be able to to that the documents should first be adopted as working group 
> documents.
> This is a formal adoption request for 
> draft-loffredo-regext-rdap-reverse-search
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT, and comment to the list, clearly stating your view.
> Please also indicate if you are willing to contribute text, review, be a 
> document shepherd, etc.
> 
> This call for adoption ends 25 Januari 2019.
> If there are no objections, and we receive enough consensus for adoption, the 
> chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Jim and Antoin.
> 
> - -- 
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
> 
> 
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-gould-regext-secure-authinfo-transfer-00.txt

[Gavin Brown]

Hi Jim,

I have reviewed the draft and I think it's a good piece of work. CentralNic 
actually already implements some of the practices in it: the  code is 
"write only" in that registrars can set it, but not see it. Feel free to 
include that in the "Implementation Status" section.

I would support the WG's adoption of this draft if it were put forward.

G.

> On 25 Jun 2019, at 13:29, Gould, James  
> wrote:
> 
> The Extensible Provisioning Protocol (EPP) Secure Authorization Information 
> for Transfer (draft-gould-regext-secure-authinfo-transfer) was posted to 
> define a BCP for securing the authorization information using the existing 
> EPP RFCs.  The overall goal is to have strong, random authorization 
> information values, that are short-lived, and that are either not stored or 
> stored as cryptographic hash values.  Review and feedback is appreciated.  
> 
> Antoin and Jim, I would like to have 10 minutes to introduce and discuss this 
> draft at the REGEXT meeting at IETF-105.  
> 
> Thanks, 
> 
> —
> 
> JG
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com <http://verisigninc.com/> 
> 
> On 6/25/19, 8:23 AM, "internet-dra...@ietf.org"  
> wrote:
> 
> 
>A new version of I-D, draft-gould-regext-secure-authinfo-transfer-00.txt
>has been successfully submitted by James Gould and posted to the
>IETF repository.
> 
>Name:  draft-gould-regext-secure-authinfo-transfer
>Revision:  00
>Title: Extensible Provisioning Protocol (EPP) Secure 
> Authorization Information for Transfer
>Document date: 2019-06-25
>Group: Individual Submission
>Pages: 17
>URL:
> https://www.ietf.org/internet-drafts/draft-gould-regext-secure-authinfo-transfer-00.txt
>Status: 
> https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/
>Htmlized:   
> https://tools.ietf.org/html/draft-gould-regext-secure-authinfo-transfer-00
>Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-gould-regext-secure-authinfo-transfer
> 
> 
>Abstract:
>   The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
>   use of authorization information to authorize a transfer.  The
>   authorization information is object-specific and has been defined in
>   the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
>   Mapping, in RFC 5733, as password-based authorization information.
>   Other authorization mechanisms can be used, but in practice the
>   password-based authorization information has been used by the
>   authorization information being set at the time of object create,
>   managed with the object update, and used to authorize an object
>   transfer request.  What has not been fully considered is the security
>   of the authorization information that includes the complexity of the
>   authorization information, the time-to-live (TTL) of the
>   authorization information, and where and how the authorization
>   information is stored.  This document defines an operational
>   practice, using the EPP RFCs, that leverages the use of strong random
>   authorization information values that are short-lived, that are not
>   stored by the client, and that are stored using a cryptographic hash
>   by the server to provide for secure authorization information used
>   for transfers.
> 
> 
> 
> 
>Please note that it may take a couple of minutes from the time of 
> submission
>until the htmlized version and diff are available at tools.ietf.org.
> 
>The IETF Secretariat
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-arias-noguchi-dnrd-objects-mapping

[Gavin Brown]

I support adoption and am willing to contribute and review.

On 26/04/2019 19:55, James Galvin wrote:
> This is a formal adoption request for  Domain Name Registration Data
> (DNRD) Objects Mapping:
> https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/.
> 
> Please review this draft to see if you think it is suitable for adoption
> by REGEXT, and comment to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review text,
> or be a document shepherd.
> 
> This call for adoption ends Thursday, 2 May 2019.
> 
> If there are no objections, and we receive enough consensus for
> adoption, the chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Antoin and Jim
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-arias-noguchi-registry-data-escrow

[Gavin Brown]

I support adoption and am willing to contribute and review.

On 26/04/2019 19:55, James Galvin wrote:
> This is a formal adoption request for Registry Data Escrow
> Specification:
> https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/.
> 
> Please review this draft to see if you think it is suitable for adoption
> by REGEXT, and comment to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review text,
> or be a document shepherd.
> 
> This call for adoption ends Thursday, 2 May 2019.
> 
> If there are no objections, and we receive enough consensus for
> adoption, the chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Antoin and Jim
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Proposal about jCard replacement

[Gavin Brown]

Hi Mario,

>> I would be happy to publish a new version of 
>> draft-brown-epp-contacts-in-rdap which uses JSContact rather than its own 
>> representation of contact data. That would glue JSContact and RDAP together.
> 
> IMHO it would be better to write a new document with the contribution of who 
> is willing to implement JSCard in his own RDAP server (you, me, maybe Andy).

I'd be very happy to contribute.

> I think other stuff has still to be discussed. For example, what to do to 
> make the transition from JCard to JSCard as smooth as possible. Should JSCard 
> become the default and JCard an optional capability or viceversa?

Good question. That's a decision for this WG to make. Adding JSContact as an 
optional extension would be straightforward: making it the default would 
essentially create RDAP 1.1 which is a somewhat more complex proposition.

> How could an RDAP server inform a client that it is able to return contact 
> information according to the JSCard format?

Unless we define a way to know an RDAP server's capabilities in advance, the 
client has no way to find out except to send a query and see what it gets back. 
As a client implementer I'm fine with this: some servers will support jCard 
forever so I need to continue to support them (even if only as legacy code). 
Some will immediately move to JSContact. Some may offer both in parallel, 
especially during an upgrade period, as we have seen during the migration of 
EPP from secDNS-1.0 to secDNS1.1.

If we need provide a way to know in advance (I'm not sure we do) then we could 
(a) alter the structure of the bootstrap file, (b) use server specification 
mechanism as you outlined at the ROW in Bangkok[1], or come up with some other 
mechanism (maybe by specify how the OPTIONS method can be used with RDAP?).

> We can have a short talk about it at the next meeting.

Alas I will not be present but will try to join remotely if possible.

G.

[1] 
http://regiops.net/wp-content/uploads/2019/05/ROW8-PPT-An-RDAP-capability-for-server-specification-provisioning-Mario-Loffredo-Maurizio-Martinelli.pdf
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] 2nd factor for Login Security Extension for EPP

[Gavin Brown]

Hi Michael,

On 23/04/2019 09:12, Michael Bauland wrote:
>
> Certificates on the other hand are not a secure factor as almost anybody
> can obtain a valid certificate.

A valid certificate provides a weak form of non-repudiation, so if an
attacker obtains (for example) a cert for example.com and uses it to do
bad stuff, then you can be reasonably certain that they have some
association with the owner or operator of that domain. One could imagine
that a server could require use of an EV cert to obtain a higher level
of assurance.

Server implementations can (and should) also tightly associate a cert
with a specific client identity, so a client that connects using a
certificate can only log in to a registrar account to which the
certificate has been associated. That's how CentralNic's implementation
works.

G.

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-secure-authinfo-transfer-00.txt

[Gavin Brown]

It's worth noting that there are "operational practices" RFCs (6781 being the 
obvious example) that do not describe a protocol, and are published as 
Informational documents. This document seems more like those than a protocol 
specification.

G.

> On 2 Jul 2019, at 06:56, Patrick Mevzek  wrote:
> 
> 
> 
> On Tue, Jun 25, 2019, at 07:29, Gould, James wrote:
>> The Extensible Provisioning Protocol (EPP) Secure Authorization 
>> Information for Transfer (draft-gould-regext-secure-authinfo-transfer) 
>> was posted to define a BCP for securing the authorization information 
>> using the existing EPP RFCs.  The overall goal is to have strong, 
>> random authorization information values, that are short-lived, and that 
>> are either not stored or stored as cryptographic hash values.  Review 
>> and feedback is appreciated.  
> 
> I have read your draft and while I can obviously share your operational
> experiences and goals to address many shortcomings of current situation
> I really believe that such document as written is not a good fit for an RFC,
> nor even for the IETF place in general.
> 
> Why? Because it only discuss policies, and not protocol matters.
> The fact that it does not define  any new EPP commands/objects nor EPP XML 
> namespace
> seems to hint clearly that this is not an EPP extension, that it has nothing
> to do with the protocol.
> 
> Things like that:
> 
>> The operational practice will not require the client
>>  to store the authorization information and will require the
>>  server to store the authorization information using a
>>  cryptographic hash.  
> 
> How the password is stored and handled at the registry is completely
> out of EPP scope. It could as well be symmetrically encrypted, and I fail
> to see even how this can be enforceable (how will you verify remotely
> how the registry stores the password?), as it is not protocol related.
> 
> Or:
> 
>> and the sponsoring registrar MUST inform the
>>  registrant of the TTL when the authorization information is provided
>>  to the registrant.
> 
> Registrars exist that do not let registrant choose passwords at creation
> (which also hopefully deter bad passwords) and just give it when requested,
> for an outgoing  transfer (since it is basically useless for anything else).
> So the TTL information will have no meaning to registrants.
> 
> Also all your process regarding TTLs force registrars to maintain state
> (when they set the password) and a machinery to change it after expiration.
> This does not provide them any gain, so there is 0 incentive for them to do 
> that,
> and could be only controlled by the registry.
> 
> It also absolutely does not take into account all cases that exist today,
> and I see absolutely no reason why the IETF would suddenly be the judge of 
> some
> registries policies.
> One example: some registries do not let registrars choose/set authInfo.
> When a transfer has to be done, the current registrar needs to use a specific 
> EPP command
> to request the registry to generate a new authInfo (which can be obtained 
> through
> a followup domain:info), which the registrant will then use at the new 
> registrar.
> This authInfo has even some time to live.
> 
> Another example: after a successful transfer, the registry automatically 
> changes
> the authInfo.
> 
> I am not claiming this is better. Or worse. I am just saying that there are
> various policies, and I see no reason for the IETF to order them from bad to 
> good.
> 
> On the opposite side I would be more happy to see attempts to extend the 
> authInfo.
> It has clearly been designed from the beginning at being extensible:
> 
>   
>
>  
>  
>
>   
> 
> and
> 
> 
>   
> 
>   
> 
> 
> 
> So in my views the current password based model per domain has died,
> and other solutions have to be searched for. Maybe there is space to pursue
> in solutions around OTP frameworks.
> 
> Any work in this area needs for me to take also into account at least the 
> related issues:
> - registry lock services
> - the whole transfer process (since authInfo serves only there), taking into 
> account
> that there may be rules applied to all gTLDs by virtue of their common 
> contracts,
> but then there are all the other registries.
> 
> 
> -- 
>  Patrick Mevzek
>  p...@dotandco.com
> 
> ___
> 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] Proposal about jCard replacement

[Gavin Brown]

Hi Mario,

I like JSContact and the current draft certainly looks good enough to be usable 
in RDAP. I imagine more work will be needed before JSContact will have feature 
parity with vCard/jCard.

I would be happy to publish a new version of draft-brown-epp-contacts-in-rdap 
which uses JSContact rather than its own representation of contact data. That 
would glue JSContact and RDAP together.

G.

> On 2 Jul 2019, at 07:58, Mario Loffredo  wrote:
> 
> Hi all,
> 
> I would like to invite you to take a look at this document: 
> https://tools.ietf.org/html/draft-stepanek-jscontact-03
> 
> It aims to define a JSON representation of contact information that fixes the 
> issues with jCard deserialization and, at the same time, expands vCard 
> semantics.
> 
> Just to give an idea of the new contact representation in the RDAP context, I 
> have implemented an ad-hoc optional capability in .it public test server 
> (e.g. https://rdap.pubtest.nic.it/domain/nic.it?jscard=1).
> 
> The draft was presented for the first time at last dispatch session in Prague 
> and, since then, some feedbacks have been posted on dispatch mailing list 
> which have contributed to improve the initial proposal.
> 
> Anyway, since the jCard replacement has been debated within this WG, it seems 
> to me quite obvious to bring it to your attention.
> 
> Any feedback will be very appreciated.
> 
> Thanks in advance,
> 
> mario
> 
> -- 
> Dr. Mario Loffredo
> Servizi Internet e Sviluppo Tecnologico
> CNR - Istituto di Informatica e Telematica
> via G. Moruzzi 1, I-56124 PISA, Italy
> E-Mail:mario.loffr...@iit.cnr.it
> Phone: +39.0503153497
> 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] RDAP RFC Update - PS or DS?

[Gavin Brown]

Hi Scott,

Forgive my ignorance, but what's the difference between a Draft Standard and a 
Proposed Standard?

+1 either way!

G.

> On 1 Aug 2019, at 17:23, Hollenbeck, Scott 
>  wrote:
> 
> Folks, during the IETF meeting we talked a little bit about the possibility 
> of re-doing the RDAP protocol specs to address clarifications and errata 
> identified as a result of implementation experience. We didn't have a lot of 
> time to talk through the possibilities, so I thought I'd start something here.
> 
> We spoke a bit in the room about the possibility of re-spinning the documents 
> as Proposed Standard RFCs. However, as long as we stick to fixing errata, 
> dealing with clarifications, etc., and not adding new features, we could make 
> a case for document updates with the goal of producing Draft Standard RFCs. I 
> believe we have enough implementation experience to meet the requirements for 
> publication as Draft Standards (see Section 4.1.2 of RFC 2026), so let me 
> throw that out there. Should we take on the update process with a goal of 
> producing Draft Standards, or do we need to make more substantial changes 
> that require a Proposed Standard re-do?
> 
> Scott
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] on jcard and jscontact migration

[Gavin Brown]

On 25 Jul 2019, at 22:43, Andrew Newton  wrote:
> In other words, who is NOT doing RDAP because of jCard? Are there any
> registries willing to step up and say they'll deploy RDAP if we move
> to JSContact?

I'm not too concerned about jCard as a barrier to server deployment. I'm more 
concerned about how it impedes *client* deployment (and consequently, migration 
of legacy whois clients to RDAP).

If there were multiple, lossless jCard <=> vCard converters, implemented in 
different (popular) programming languages, then I would be less concerned. But 
there aren't (and I doubt there ever will be).

G.

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] rfc7484bis

[Gavin Brown]

> On 11 Aug 2020, at 19:33, Marc Blanchet  wrote:
> 
> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
> 
>> On Tue, Aug 4, 2020, at 14:32, Gavin Brown wrote:
>>> 1. client implementers should be advised to prefer https:// base URLs
>>> over http:// base URLs.
>> 
>> I think this is already addressed by this text in the current RFC:
>> "
>>   Per [RFC7258], in each array of base RDAP URLs, the secure versions
>>   of the transport protocol SHOULD be preferred and tried first.  For
>>   example, if the base RDAP URLs array contains both HTTPS and HTTP
>>   URLs, the bootstrap client SHOULD try the HTTPS version first.
>> "
> 
> Gavin,
> Patrick is right. text was already there. ;-) Happy with the current text?

No issues here! My second point (about identical responses from every listed 
server) still stands though.

Here's my proposed text, which could be inserted below the aforementioned 
paragraph in Section 3:

"Registrants of entries in bootstrap registries SHOULD ensure, where multiple 
base URLs are listed for a given set of entries, that all listed RDAP servers 
produce the same response to a given query."

More than happy to accept feedback on the above.

G.

--
Gavin Brown
Head of Registry Services and Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnic.com

Tel: +44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] rfc7484bis

[Gavin Brown]

Hi Marc,

> as Scott is updating RFC7482,RFC7483 for standard level, I’m doing the same 
> for rfc7484. I haven’t heard major issues or major fixes to be made for 
> rfc7484. I have a few wording fixes only at this time. There were some 
> discussions on enhancing RFC7484 for other use cases, but never went far.
> if anyone has a something to raise for RFC7484, please send me email asap.

RFC 7484 doesn't provide any guidance for client implementers about how to 
select a base RDAP URL when the services array contains more than one entry. As 
a result I suspect that in this scenario different implementations will behave 
in different ways, and users are at risk of seeing different responses 
depending on the client they use.

My suggestions are that:-

1. client implementers should be advised to prefer https:// base URLs over 
http:// base URLs.

2. server operators should be advised that if multiple base URLs with the same 
scheme are present in an entry, then all the RDAP endpoints referenced by these 
base URLs must return identical responses (for the same RDAP query).

Thanks,

G.

--
Gavin Brown
Head of Registry Services and Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnic.com

Tel: +44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] rfc7484bis

[Gavin Brown]

> On 12 Aug 2020, at 17:18, Marc Blanchet  wrote:
> 
> well, already added text in the published draft yesterday.
> 
> https://www.ietf.org/internet-drafts/draft-blanchet-regext-rfc7484bis-00.txt
> 
> extract of my added text:
> « All RDAP endpoints referenced by the URLs in the array MUST return
>   identical responses for the same RDAP query. »
> 
> would that work?

Looks good to me.

G.

--
Gavin Brown
Head of Registry Services and Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnic.com

Tel: +44.7548243029

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6AE.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-epp-registry-maintenance

[Gavin Brown]

Hi Antoin,

I've reviewed the document and support its submission to the RFC Editor queue.

G.

> On 29 Mar 2021, at 13:49, 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-epp-registry-maintenance/
> 
> EXTRA ATTENTION: This is the second WGLC for this document. During the first 
> WGLC, there were still some substantial comments to be addressed, and there 
> was not enough positive feedback to declare consensus on this document. Let’s 
> do better this time and please take the time to 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. Since 
> we have 3 authors, we need more reviewers to state support!
> 
> This WG last call will end at close of business, Monday, 12 April 2021.
> 
> 
> The document shepherd for this document is James Galvin.
> 
> Regards,
> 
> Antoin and Jim
> 
> 
> 
> 
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EXTENDED: Re: CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

[Gavin Brown]

Hi,

I support adoption of this document and will continue to contribute to it.

G.

> On 10 Feb 2021, at 19:33, James Galvin  wrote:
> 
> The Chairs would like to extend this CALL FOR ADOPTION because we’d like to 
> separate out an issue that has come up in the discussion of this adoption.  
> We are hoping that this clarity will address the concern that has been raised.
> 
> This document actually covers two distinct issues.
> 
> 1. A specification for jsContact.
> 2. A proposal for migrating to jsContact from jCard.
> 
> There are words suggesting that jCard would be deprecated as part of this and 
> the question has been raised on the list as to whether or not this is 
> actually a reality.
> 
> The Chairs would like to propose that we separate out the question of whether 
> or not jCard will be deprecated.  That is better considered as a separate 
> question.
> 
> Since there is precedent in the IETF for documenting alternate ways of 
> meeting a requirement, here is what we propose.
> 
> This CALL FOR ADOPTION is to commit to a specification of jsContact.  The 
> specification would be permitted to document how one could migrate from jCard 
> to jsContact.  The starting point for this work is 
> draft-loffredo-regext-rdap-jcard-deprecation-03.
> 
> If this document is adopted, then we will need to consider the relationship 
> between the use of jsContact and jCard.  The IESG will ask us this question 
> as part of considering the publication of any document we develop.  This will 
> effect the potential status of the document, e.g., Proposed Standard vs 
> Experimental.  More specifically, we will need to consider whether there is 
> support to migrate to something new given the legacy deployment.  It is 
> appropriate to have this discussion within the working group.
> 
> With all that in mind, here is the revised, extended CALL FOR ADOPTION:
> 
> 
> This is a formal adoption request for “Using JSContact in Registration Data 
> Access Protocol (RDAP) JSON Responses”:
> 
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/
> 
> This document will serve as the starting point for documenting jsContact.  It 
> may also document how to migrate from jCard to jsContact, depending on the 
> consensus of the working group.
> 
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT for the stated purpose, and comment to the list, clearly stating your 
> view.
> 
> If adopted, the document will be renamed as follows: 
> draft-ietf-regext-rdap-jscontact.
> 
> Please indicate if you are willing to contribute text, review text, or be a 
> document shepherd.
> 
> Please also indicate any preference you have for a proposed milestone date.
> 
> This call for adoption ends Monday, 22 February 2021.
> 
> If there are no objections, and we receive enough consensus for adoption, the 
> chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Antoin and Jim
> 
> 
> 
> 
> On 18 Jan 2021, at 9:29, James Galvin wrote:
> 
>> This is a formal adoption request for “Using JSContact in Registration Data 
>> Access Protocol (RDAP) JSON Responses”:
>> 
>> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/
>> 
>> Please review this draft to see if you think it is suitable for adoption by 
>> REGEXT, and comment to the list, clearly stating your view.
>> 
>> Please indicate if you are willing to contribute text, review text, or be a 
>> document shepherd.
>> 
>> Please also indicate any preference you have for a proposed milestone date.
>> 
>> This call for adoption ends Monday, 1 February 2021.
>> 
>> If there are no objections, and we receive enough consensus for adoption, 
>> the chairs will consider this document adopted.
>> 
>> Thanks,
>> 
>> Your REGEXT co-chairs Antoin and Jim
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Confusion around non-uniqueness of nameserver objects

[Gavin Brown]

Hi all,

I was recently contacted by an otherwise clueful person who was confused 
because an RDAP query for a particular nameserver object seemingly showed the 
wrong sponsoring registrar.

Upon investigation, it was revealed that the nameserver in question was 
subordinate to domain in another TLD. The user was expecting the RDAP record to 
show the registrar of the sponsoring registrar of the parent domain, rather 
than the registrar who happened to create it, because two different TLDs can 
use two unrelated registry systems, and there is no synchronisation between 
them, therefore nameserver objects are not globally unique in the way that 
domain names are.

It occurred to me that it may be possible to mitigate this confusion: in 
response to nameserver queries, an RDAP server can include a "related" link to 
the "authoritative" RDAP server (constructed using the bootstrap registry).

My question to this group is how useful this would be? Does it solve a real 
problem?

Thanks,

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Confusion around non-uniqueness of nameserver objects

[Gavin Brown]

On 21 Dec 2021, at 16:16, Hollenbeck, Scott  wrote:
> 
>> [snip]
>> 
>> I was recently contacted by an otherwise clueful person who was confused
>> because an RDAP query for a particular nameserver object seemingly
>> showed the wrong sponsoring registrar.
>> 
>> Upon investigation, it was revealed that the nameserver in question was
>> subordinate to domain in another TLD. The user was expecting the RDAP
>> record to show the registrar of the sponsoring registrar of the parent
>> domain, rather than the registrar who happened to create it, because two
>> different TLDs can use two unrelated registry systems, and there is no
>> synchronisation between them, therefore nameserver objects are not
>> globally unique in the way that domain names are.
>> 
>> It occurred to me that it may be possible to mitigate this confusion: in
>> response to nameserver queries, an RDAP server can include a "related" link
>> to the "authoritative" RDAP server (constructed using the bootstrap
>> registry).
>> 
>> My question to this group is how useful this would be? Does it solve a real
>> problem?
> 
> [SAH] Sounds useful to me. What did the otherwise clueful person think?

He agreed that the above solution would be effective.

G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

[Gavin Brown]

their matters appear very similar to me. 
>>> 
>>> Using JSContact inside RDAP is basically an extension. 
>>> 
>>> If we remove stages 3 and 4 of the transition from the document, we simply 
>>> have an RDAP extension that is or isn't implemented  by a server.
>>> 
>>> This extension can be firstly signaled by the server, then requested by the 
>>> client and consequently returned by the server just as it happens for the 
>>> EAI extension in the EPP context. 
>>> 
>>>  
>>> 
>>> Best,
>>> 
>>> Mario
>>> 
>>>  
>>> 
>>> Il 06/12/2021 15:29, Antoin Verschuren ha scritto:
>>> Hi all, 
>>>  
>>> In addition to the questions from Mario, we still need to discuss the 
>>> status of this document as discussed during the IETF112 meeting:
>>>  
>>> "the document doesn’t have designated status; it was adopted without a 
>>> status (on purpose). We need to think about the implications. Encouraged 
>>> group to discuss/comment on the list”
>>>  
>>> Meaning that because jCard is not depreciated with publishing this 
>>> document, what will the status of this document be? We cannot have 2 
>>> standards, so we need to say something about it.
>>>  
>>> Jim and Antoin
>>>  
>>> 
>>> 
>>> Op 27 nov. 2021, om 09:04 heeft Mario Loffredo  
>>> het volgende geschreven:
>>>  
>>> Hi folks,
>>> this new version addresses the feedback provided by Jasdip except for the 
>>> following two points left for WG discussion:
>>> 1) In the sentence "To aid interoperability, RDAP providers are RECOMMENDED 
>>> to use as map keys the following string values and labels defined in 
>>> [RFC5733].", should  "are RECOMMNEDED   to" be 
>>> replaced with "MUST"?
>>> 2)  Does the portion of the spec for jCard to JSContact transition 
>>> signaling add significant implementation overhead for RDAP servers and 
>>> clients? Could an out-of-band (OOB) method have been employed?
>>>  
>>> Three more implementations were included.
>>>  
>>> Best,
>>> Mario
>>> 
>>> 
>>>  Messaggio Inoltrato  
>>> Oggetto: 
>>> New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt
>>> Data: 
>>> Fri, 26 Nov 2021 23:53:34 -0800
>>> Mittente: 
>>> internet-dra...@ietf.org
>>> A: 
>>> Gavin Brown , Mario Loffredo 
>>> 
>>> 
>>> 
>>> 
>>> A new version of I-D, draft-ietf-regext-rdap-jscontact-04.txt
>>> has been successfully submitted by Mario Loffredo and posted to the
>>> IETF repository.
>>> 
>>> Name: draft-ietf-regext-rdap-jscontact
>>> Revision: 04
>>> Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON 
>>> Responses
>>> Document date: 2021-11-26
>>> Group: regext
>>> Pages: 22
>>> URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-04.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
>>> Htmlized: 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact
>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-jscontact-04
>>> 
>>> Abstract:
>>> This document describes an RDAP extension which represents entity
>>> contact information in JSON responses using JSContact.
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> ___
>>> 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
>>> -- 
>>> Dr. Mario Loffredo
>>> Technological Unit “Digital Innovation”
>>> Institute of Informatics and Telematics (IIT)
>>> National Research Council (CNR)
>>> via G. Moruzzi 1, I-56124 PISA, Italy
>>> Phone: +39.0503153497
>>> 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
> -- 
> Dr. Mario Loffredo
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: 
> http://www.iit.cnr.it/mario.loffredo

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Gavin Brown]

Hi Jim and Mario,

> On 2 Mar 2022, at 13:01, Gould, James  wrote:
> 
> Mario,
>  
> Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel with 
> EPP/TLS a while back for many years.  In the end, there were very few 
> registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m not sure at 
> this point whether there is hunger from the registrars to implement 
> EPP/HTTPS. 

At least one registrar (DNSimple) had a go at writing an EPP over HTTPS spec a 
few years ago, regrettably it didn't get very far (for which I am partly to 
blame):

https://github.com/aeden/epp-over-http

I think now is a good time to reassess the appetite for EPP over HTTPS. As we 
all move to the cloud, where almost everything uses HTTP as a substrate, it 
becomes harder to deploy protocols that aren't based on HTTP in a cloud-native 
way, both on the client side and the server side.

From the security point of view, while EPP has a relatively small attack 
surface, if you're a registry, you're somewhat limited in terms of the 
third-party security services you can deploy to protect it. The same is true of 
whois, but at least we know that whois will one day be replaced by RDAP, which 
is HTTP based. I look forward to one day putting my entire infrastructure 
behind $YOUR_CLOUD_BASED_REVERSE_PROXY_OF_CHOICE - which necessitates retiring 
(or at least deprecating) ports 43 and 700.

G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] New Version Notification for draft-ietf-regext-epp-ttl-02.txt

[Gavin Brown]

Hi all,

Please look at this document. It contains a "straw man" implementation of a 
syntax for supporting TTLs for different record types.

I do not personally like this syntax but have struggled to find one that both 
(a) seems intuitive and (b) can be fully validated using only the XML schema: 
the *easy* approach would be to have looser XML schema and then use MUSTs and 
MUST NOTs in the text, but I'd like to avoid that if I can.

So, I am asking for suggestions on how to do it better. I would be very sad if 
the current model ended up being the final one!

G.

On 10/09/2023, 14:00, internet-dra...@ietf.org 
<mailto:internet-dra...@ietf.org wrote:

A new version of Internet-Draft draft-ietf-regext-epp-ttl-02.txt has been
successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-ietf-regext-epp-ttl
Revision: 02
Title:Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live 
(TTL) values
Date: 2023-09-05
Group:regext
Pages:18
URL:  https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-02.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-02

Abstract:

   This document describes an extension to the Extensible Provisioning
   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
   (TTL) value for domain name delegation records.

About this draft

   This note is to be removed before publishing as an RFC.

   The source for this draft, and an issue tracker, may can be found at
   https://github.com/gbxyz/epp-ttl-extension.


The IETF Secretariat

-- 
Gavin Brown 
Principal Engineer, GDS Technical Services 
Internet Corporation for Assigned Names and Numbers (ICANN) 

https://www.icann.org


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] JSON Schema for RDAP RFC-9083

[Gavin Brown]

Hi there,

Further to Scott’s email, some time ago Mario and Maurizio from .IT created 
some schemas which I pinched and put in this Git repository:

https://github.com/gbxyz/rdap-json-schemas

These are based on RFC 7483, but with a bit of work could be updated and form 
the basis of a draft.

G.

> On 31 Aug 2023, at 15:58, Hollenbeck, Scott 
>  wrote:
> 
> There is no RFC that I can find that describes JSON Schema. That’s not 
> surprising, since when I did some reading on the web site described below I 
> found references to multiple expired I-Ds:
>  https://json-schema.org/specification.html
>  The lack of a formal specification certainly contributed to there being 
> nothing said in 9083, but it’s been a while and I just don’t remember the 
> topic ever coming up. There’s no mention of “JSON Schema” in the mailing list 
> archive that I could find.
>  It might or not be valuable to develop a schema for RDAP responses. You 
> should describe your goals first, and then we can discuss if/how JSON Schema 
> helps meet those goals.
>  Scott
>  From: Sammy Mishal  
> Sent: Wednesday, August 30, 2023 1:55 PM
> To: regext@ietf.org
> Cc: Hollenbeck, Scott ; dev-t...@d3serve.xyz; 
> z...@d3serve.xyz
> Subject: [EXTERNAL] JSON Schema for RDAP RFC-9083
>  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 of IETF,
> 
> We are working on a product that depends on JSON response from RDAP protocol.
> We came across RFC-9083; realizing it doesn't specify a JSON Schema format 
> (https://json-schema.org/).
> 
> Do you know if there is any RFC specifying the JSON schema format for RDAP 
> response?
> If not, any rationale why not, or is it a good idea for us to contribute a 
> JSON schema RFC?
>  Sami Mis'hal and Victor Zhou, 
> D3Serve Labs
> Email: dev-t...@d3serve.xyz
> ___
> 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] [Ext] New Version Notification for draft-ietf-regext-epp-ttl-02.txt

[Gavin Brown]

Hi Marc,

Thanks for your review. I will spare Brian the responsibility of replying on my 
behalf :) My comments are inline below.

> in the EPP command mapping there is a mention on a registry policy regarding 
> TTL values which must/should be within server’s permitted range. And the 
> subject returns in the Security considerations chapter. Is it an idea to 
> mention this already in the general part of this document?

I believe this topic is addressed with sufficient detail and prominence in the 
draft. Sections 6 and 7 provide guidance to implementers on what should be 
taken into consideration when defining server policy: beyond this and we enter 
the realm of *specifying* policy which I don't believe is appropriate for this 
document.

>  Question on 2.2  element. Why is this element not OPTIONAL? What am 
> I overseeing by thinking it should be optional, as is with the other elements 
> within de domain object?

Because a delegation doesn't exist if no NS records are present. If no NS 
records are present then no other record types will be present. Therefore, the 
NS element is mandatory.

> Remark 1 on 3.1.1. In the example of the domain:info command the server 
> responds with ttl:DS while there is no DS record within the domain object. I 
> think it should mention a DS record, otherwise you’re working against (in 
> part) the remark you shouldn’t use ttl elements for which there are no 
> objects.

Thanks, that'll be fixed in the next version.

> Remark 2 on 3.1.1. In the example  and  are returned while 
> the domain object uses hostObjs. Should these values not be part of the 
> hostObjs?

The specification allows for TTLs for A and  records to be set on a domain, 
that propagate down to subordinate hosts (if those hosts don't have explicit 
TTLs).

The extension also needs to allow for the host attribute model, however this is 
not explicitly stated in the current text (something I will fix).

>   Remark on 3.2.1: for the host create command example I see the use of 
>  instead of the  and  elements which I suspected to 
> be used. What will the  achieve when used within the host object 
> creation?

 is used when the same value is used for all record types. You would 
only use  and  if you wanted a different TTL for A and AAA 
records, respectively.

Perhaps this approach is confusing? Should we drop  and use 
 exclusively?

>  Typo in chapter 5 last paragraph: EPP servrers -> EPP servers.
>  That’s for now. Still looking into another scheme to make this to succeed…

Thanks again for your feedback.

G.

>  Best regards,
> Marc Groeneweg
>   From: Brian Dickson 
> Date: Thursday, 14 September 2023 at 20:22
> To: Marc Groeneweg 
> Cc: Gavin Brown , regext@ietf.org 
> Subject: Re: [regext] [Ext] New Version Notification for 
> draft-ietf-regext-epp-ttl-02.txt
>   On Tue, Sep 12, 2023 at 6:34 AM Marc Groeneweg 
>  wrote:
> Hi Gavin,
>  I am going to review your draft. I see you’re using a ttl object for adding, 
> updating and removing ttls on a role type. Is it also an idea to extend 
> existing objects (domain and host) with a ttl field? I know this is a 
> different approach and perhaps more complex. But when I look at an example on 
> changing a hostObj with 2 IPv4 addresses the ttl for “A” will apply for both 
> IPv4 addresses I guess. When extending on separate fields it should be 
> possible to get a ttl for each address right? And then there’s no need to 
> give a ttl a role like “A” or “”.
>  Speaking as a DNS person ("expert" might be overstating things): the TTL of 
> any set of records with the same owner name (i.e. FQDN) and type (RRTYPE, 
> such as A or ) absolutely MUST be identical. This is part of the core DNS 
> specification, and set in stone for all DNS implementations. It carries over 
> to DNSSEC as well.
>  So, please ensure the EPP specifications related to TTL adequately prevent 
> any deviation from this requirement.
>  Brian
>Really, it’s just a blunt idea from my side, and not thought through yet .
>  Forgot to mention thank you for taking the lead in this draft, as it’s 
> mentioned a lot in OARC meetings that this would help in the daily DNS 
> operations…
>  Best regards,
> Marc Groeneweg
>  From: regext  on behalf of Gavin Brown 
> 
> Date: Monday, 11 September 2023 at 14:28
> To: regext@ietf.org 
> Subject: Re: [regext] [Ext] New Version Notification for 
> draft-ietf-regext-epp-ttl-02.txt
> [Some people who received this message don't often get email from 
> gavin.br...@icann.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi all,
> 
> Please look at this document. It contains a "straw man" implementation of a 
> syntax for supporting TTLs for different record types.
> 
&

Re: [regext] Call for agenda items IETF 118

[Gavin Brown]

Those interested in this topic may want to watch the recording of a panel 
session I ran at the 11th Registration Operations Workshop back in 2022:

https://icann.zoom.us/rec/share/LbpHF4gIkTXDZUU8k1FAEX4Wj3heVjooXoL1rWBsRDMLqd2fyVrlZ31VlSm7Atyq.mPnxau32-dlHUoH8

Passcode: !@.!&7+ver - skip to 02:35:07 to go straight to the start of the 
discussion.

Mario’s slides from this session are here:

https://regiops.net/sites/default/files/documents/8.1-ROW11-Mario%20Loffredo%20-%20EPP%20over%20HTTP%20panel.pdf

G.

> On 20 Oct 2023, at 13:43, Antoin Verschuren  
> wrote:
> 
> Ok, Maarten, I squeezed you in for the 10 minutes Andy gave up.
> Thanks Andy. I have put your 2 presentations in the “If time permits” 
> section, but I don’t expect we will have time.
> 
> Maarten:
> You can upload your presentation to 
> https://datatracker.ietf.org/meeting/118/session/31683/propose_slides
> Or you can send them to the chairs to do so when ready.
> Please have your slides uploaded at latest 2023-11-08 COB so our WG can 
> prepare and slides are available in Meetecho.
> Will you present in person or remote?
> 
> Regards,
> 
> Antoin
> 
>> Op 20 okt. 2023, om 11:17 heeft Pawel Kowalik  het 
>> volgende geschreven:
>> 
>> I copy on that. It was a topic of wider interest during the last CENTR Tech 
>> meeting and it would be good to have a wider IETF community view on this in 
>> terms of standards.
>> 
>> Kind Regards,
>> 
>> Pawel
>> 
>> Am 20.10.23 um 10:13 schrieb Maarten Wullink:
>>> Andy,
>>> 
>>> Thank you for your kind offer to give up your agenda items.
>>> It would be nice if we could have a discussion about  RESTful EPP in Prague
>>> 
>>> 
>>> Maarten
>>> 
 Op 19 okt 2023, om 14:53 heeft Andrew Newton  het volgende 
 geschreven:
 
 [You don't often get email from a...@hxr.us. Learn why this is important 
 at https://aka.ms/LearnAboutSenderIdentification ]
 
 Antoin,
 
 I'm willing to give up agenda items 6.iv. (rdap-extensions) and 6.v.
 (rdap-x-media-type) to give Maarten 10 minutes to discuss restful EPP.
 To me that seems like a better use of face-to-face time as both of my
 drafts got time at the last IETF.
 
 -andy
 
 On Tue, Oct 17, 2023 at 3:27 PM Antoin Verschuren
  wrote:
> Hi Maarten,
> 
> Unfortunately, our agenda for IETF 118 is already fully booked with no 
> space to overrun.
> Perhaps we should consider a 2 hour meeting request for next IETF 119.
> 
> Regards,
> 
> Antoin
> 
>> Op 16 okt. 2023, om 17:52 heeft Maarten Wullink 
>>  het volgende geschreven:
>> 
>> Hi Antoin,
>> 
>> Maybe a bit late, but would it be possible to add a few minutes for a 
>> discussion about the usefulness of REST enabled EPP.
>> 
>> Thanks!
>> 
>> Maarten
>> 
>> 
>> see below for my motivation from a mail to the list last week:
>> 
>> 
>> Seeing that more and more registries are moving their infrastructure 
>> into the cloud, it might be a good time to take look again at the 
>> transport used for EPP.
>> Adding a method for easily running EPP services in the cloud could make 
>> things easier for registries and registrars.
>> 
>> some of the advantages i see are:
>> 
>> - scaling epp services will be easier, run many stateless epp services
>> - rate limiting HTTP is easy compared to EPP TCP session and can use 
>> standard tooling for this
>> - more in line with modern web development (restful APIs)
>> - good support for monitoring of http based services
>> 
>> 11 years ago we proposed to add a restful transport option (see url to 
>> draft below), at the time it got no traction but things haven changed 
>> quiet a bit since then, is this something worthy of our time to look 
>> into again?
>> 
>> 
>> https://datatracker.ietf.org/doc/html/draft-wullink-restful-epp-00
>> 
>> ___
>> 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
>>> 
>>> ___
>>> 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
> 
> ___
> 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

[regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-02.txt

[Gavin Brown]

Submitted version -02 with a first stab at both domain and host mapping.

G.

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-regext-brown-epp-ttl-02.txt
> Date: 27 September 2022 at 13:48:36 BST
> To: "Gavin Brown" 
> 
> 
> A new version of I-D, draft-regext-brown-epp-ttl-02.txt
> has been successfully submitted by Gavin Brown and posted to the
> IETF repository.
> 
> Name: draft-regext-brown-epp-ttl
> Revision: 02
> Title:Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
> Document date:2022-09-27
> Group:Individual Submission
> Pages:15
> URL:
> https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-02.txt
> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-regext-brown-epp-ttl-02
> 
> Abstract:
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt

[Gavin Brown]

Thanks Rick and Jim for the feedback. I am happy to accept the idea of the 
extension working for both domain and host objects and will work towards making 
that a part of the next version.

One point for possible further discussion is the "priority" of TTL values: I am 
going to state that the TTL value of the host object takes priority over the 
TTL of the superordinate domain. So if:

com default TTL: 172800
example.com TTL: 3600:
ns1.example.com TTL: (undefined)

then the TTL for NS records delegating to ns1.example.com should be 3600, but if

com default TTL: 172800
example.com TTL: 3600:
ns1.example.com TTL: 86400

then the TTL should be 86400.

G.

> On 26 Sep 2022, at 13:41, Rick Wilhelm  wrote:
> 
> Gavin,
>  
> Just a +1 for having this extension cover both the domain and host objects.
>  
> The sibling glue model has enough deployment that having the extension cover 
> both models makes sense.
>  
>  
> One other thing… and this is not a call for a change, just concurrence to an 
> existing design choice that is in the draft.  I like the behavior described 
> for Server Processing of TTL Values (Section 4, paragraph 2) where the 
> description covers the scenario where the TTL values are outside the range.
>  
> The doc says to reject the command with a 2004 “Parameter value range error”. 
>  I was wondering if this might be “too aggressive” for a  (it clearly 
> makes sense for an ), but after some thought, I agree with the 
> current behavior.
>  
> First, it’s consistent.  Second, since the extension is optional (and since 
> hosts links are optional on domain::create, the extension is “2x-optional”), 
> it is better to “fast fail” due to validation enforcement.  Because to let 
> the  go through and have the invalid values flagged with only 
> a warning is more likely to lead to confusion in the future.  That is, a 
> client that is not properly respecting the limits of the TTL values is also 
> unlikely to be heading a hypothetical warning value.
>  
> So, bottom line, after some thought, I like the way that this works.
>  
>  
> Thanks
> Rick
>  
>  
>  
>  
>  
> From: regext  on behalf of Gould, James 
> 
> Date: Monday, September 19, 2022 at 9:48 AM
> To: gavin.br...@centralnic.com , 
> thomas.co...@knipp.de
> Cc: regext@ietf.org 
> Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
> draft-regext-brown-epp-ttl-01.txt
> 
> CAUTION: This email came from outside your organization. Don’t trust emails, 
> links, or attachments from senders that seem suspicious or you are not 
> expecting.
> 
> Gavin,
> 
> The TTL for the A/ records need to be applied to the host object and the 
> TTL for the NS and DS records need to be applied to the domain object. 
> Setting the A/ TTL at the host object level would apply to registries 
> that implement sibling glue as well as CentralNic and TANGO that implement 
> in-bailiwick only glue. 
> 
> -- 
> 
> JG
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com <http://verisigninc.com/>
> 
> On 9/16/22, 9:17 PM, "regext on behalf of Gavin Brown" 
>  wrote:
> 
> Hi Thomas, 
> 
> Thanks for the suggestions. I will add them to the next version.
> 
> G.
> 
> > On 15 Sep 2022, at 01:11, Thomas Corte (TANGO support) 
> >  wrote:
> > 
> > On 9/14/22 13:35, Gavin Brown wrote:
> > 
> >> Greetings all,
> >> 
> >> Many years ago CentralNic had a proprietary EPP extension for managing
> >> the TTL values of domain names. ...
> >> 
> >> However I've had a bit of feedback about the draft since then, so I've
> >> just published a new version and am now sharing it with the WG for
> >> feedback.
> > 
> > I have two comments:
> > 
> > 1) The specification should probably address the effect of the TTLs on 
> > IDN variants. If a registry supports IDN variants as attributes of a 
> > domain name (either automatically added or via an extension), they will 
> > usually add some DNS records dedicated to these variants to the TLD zone, 
> > so the spec should specify that the same TTL is applied to these 
> > dedicated records as well. If IDN variants are managed as their own 
> > objects, they can receive their own specific TTL values.
> > 
> > 2) I'd suggest to add this boilerplate text (or something similar) to the 
> > draft:
> > 
> > "EPP uses XML namespaces to provide an extensible object management
> > framework and to identify 

Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt

[Gavin Brown]

Hey Jim,

> On 14 Sep 2022, at 13:35, Gould, James  wrote:
> 
> Gavin,
>  
> Thank you for publishing a new version of the draft.  I have the following 
> feedback:
>  
>   • Shouldn’t the track be Standards Track instead of Experimental since 
> this seems very straight forward?

Since it's current an individual submission, I've used Experimental, but if the 
WG decides to adopt it, I will change it to Standards Track.

>   • Shouldn’t the A and  TTL apply to the Host object instead of the 
> Domain Name object if using the host objects model?  If so, it may make sense 
> to have the extension extend both the Domain Name Object (RFC 5731) and the 
> Host Object (RFC 5732)?  The A and  TTL would apply to Domain Name Object 
> when using the host attributes model and the A and  TTL would apply to 
> the Host Object when using the host objects model.   

In our implementation, glue records are only published if the superordinate 
domain is delegated to them, and the current specification assumes the same 
design choice. However this is obviously not true for other registries, so 
being able to change the TTL on a host object independently of the 
superordinate domain may be needed to account for scenarios where the client 
wishes to change the TTL of all NS records *except* those of the superordinate 
domain. However I am not sure if this is a scenario that justifies the 
additional complexity entailed - but I'd appreciate the list's input on that 
point.

>   • For notifying about out-of-band changes, I like the reference to the 
> use of the EPP Change Poll Extension (RFC 8590); although I’m not sure what 
> it means to have the “EPP message queue and/or” language there.  My 
> recommendation is to just reference the EPP Change Poll Extension for 
> implementing the out-of-band change. 

Thanks, I'll consider this for the next version.

G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

[Gavin Brown]

Greetings all,

Many years ago CentralNic had a proprietary EPP extension for managing the TTL 
values of domain names.

After the Philadelphia IETF meeting, I was contacted by some WG members about 
reviving this extension for possible adoption.

So I created a new I-D to describe the extension and submitted it to the Data 
Tracker, but didn't do much else.

However I've had a bit of feedback about the draft since then, so I've just 
published a new version and am now sharing it with the WG for feedback.

Thanks,

Gavin.

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-regext-brown-epp-ttl-01.txt
> Date: 14 September 2022 at 12:26:38 BST
> To: "Gavin Brown" 
> 
> 
> A new version of I-D, draft-regext-brown-epp-ttl-01.txt
> has been successfully submitted by Gavin Brown and posted to the
> IETF repository.
> 
> Name: draft-regext-brown-epp-ttl
> Revision: 01
> Title:Extensible Provisioning Protocol (EPP) Mapping for DNS 
> Time-To-Live (TTL) values
> Document date:2022-09-14
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-01.txt
> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-regext-brown-epp-ttl-01
> 
> Abstract:
>   This document describes an extension to the Extensible Provisioning
>   Protcol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

[Gavin Brown]

Hi Thomas, 

Thanks for the suggestions. I will add them to the next version.

G.

> On 15 Sep 2022, at 01:11, Thomas Corte (TANGO support) 
>  wrote:
> 
> On 9/14/22 13:35, Gavin Brown wrote:
> 
>> Greetings all,
>> 
>> Many years ago CentralNic had a proprietary EPP extension for managing
>> the TTL values of domain names. ...
>> 
>> However I've had a bit of feedback about the draft since then, so I've
>> just published a new version and am now sharing it with the WG for
>> feedback.
> 
> I have two comments:
> 
> 1) The specification should probably address the effect of the TTLs on 
> IDN variants. If a registry supports IDN variants as attributes of a 
> domain name (either automatically added or via an extension), they will 
> usually add some DNS records dedicated to these variants to the TLD zone, 
> so the spec should specify that the same TTL is applied to these 
> dedicated records as well. If IDN variants are managed as their own 
> objects, they can receive their own specific TTL values.
> 
> 2) I'd suggest to add this boilerplate text (or something similar) to the 
> draft:
> 
>   "EPP uses XML namespaces to provide an extensible object management
>framework and to identify schemas required for XML instance parsing
>and validation.  These namespaces and schema definitions are used to
>identify both the base protocol schema and the schemas for managed
>objects.  The XML namespace prefixes used in examples (such as the
>string "ttl" in "xmlns:ttl") are solely for illustrative purposes.  A
>conforming implementation MUST NOT require the use of these or any
>other specific namespace prefixes."
> 
> This is a pet peeve of mine, as some registries still haven't managed to 
> implement this correctly.
> 
>> In our implementation, glue records are only published if the
>> superordinate domain is delegated to them, and the current
>> specification assumes the same design choice. However this is
>> obviously not true for other registries, so being able to change the
>> TTL on a host object independently of the superordinate domain may be
>> needed to account for scenarios where the client wishes to change the
>> TTL of all NS records *except* those of the superordinate domain.
>> However I am not sure if this is a scenario that justifies the
>> additional complexity entailed - but I'd appreciate the list's input
>> on that point.
> 
> Our own TANGO system's zone generation also suppresses glue records if 
> they're unnecessary, so I'd agree that the extra complexity shouldn't be 
> required.
> 
> Best regards,
> 
> Thomas
> 
> -- 
> TANGO REGISTRY SERVICES®
> Knipp Medien und Kommunikation GmbH    Thomas 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
> 
> 
> 
> 
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-03.txt

[Gavin Brown]

Hi all,

A couple of days ago I uploaded a new version draft-regext-brown-epp-ttl.

This version adds a new extension element, , which specifies the 
date and time after which a "custom" TTL should revert to the default.

Feedback welcome - I am hoping the WG will be able to pick this document up in 
the near future.

Gavin.

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-regext-brown-epp-ttl-03.txt
> Date: 16 November 2022 at 16:12:04 GMT
> To: "Gavin Brown" 
> 
> 
> A new version of I-D, draft-regext-brown-epp-ttl-03.txt
> has been successfully submitted by Gavin Brown and posted to the
> IETF repository.
> 
> Name: draft-regext-brown-epp-ttl
> Revision: 03
> Title:Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
> Document date:2022-11-16
> Group:Individual Submission
> Pages:16
> URL:
> https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-03.txt
> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-regext-brown-epp-ttl-03
> 
> Abstract:
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-epp-eai Path Forward

[Gavin Brown]

I support Jim’s proposal – the “cardinality of two” option is unnecessarily 
complex and would require more work to implement on client and server side for 
little benefit.

G.

On Thursday, March 2, 2023 at 7:50 AM, Gould, James 
jgo...@verisign.com wrote:

I’ve discussed the path forward for draft-ietf-regext-epp-eai with some working 
group participates and I have concern of the current path that the draft is 
taking with the support for an alternate e-mail address, whether it be either 
ASCII, SMTPUTF8, or either.  There are system and policy impacts associated 
with the requirement to collect and transmit an additional e-mail address 
across EPP RFCs (e.g., RFC 5733, RFC 7848, RFC 8543), where the end goal of 
draft-ietf-regext-epp-eai was to support the use of SMTPUTF8 e-mail values with 
the appropriate signaling by the server and client.  I realize that the term 
“cardinality” was not popular with some, but the inclusion of an alternative 
e-mail across all EPP extensions that include an e-mail address does make a 
crosscutting cardinality change from one to two.  The registry needs to support 
either ASCII or SMTPUTF8 addresses to enable the registrars, which have the 
relationship with the registrant, to make the decision what form of e-mail to 
accept.  In hindsight, I believe the “Change of Cardinality to One or Two 
(ASCII or SMTPUTF8)” recommendation from the IETF-115 REGEXT meeting that was 
incorporated into draft-ietf-regext-epp-eai-17 is the wrong option.  We should 
keep the cardinality of one to provide the needed support for SMTPUTF8 in the 
registry for the registrars to make the decision what to collect and pass to 
the registry.  I provide the options below for consideration by the working 
group:
1.   Cardinality of One – The approach taken in 
draft-ietf-regext-epp-eai-16, where the server (registry) supports either 
SMTPUTF8 or ASCII addresses for a decision by the client (registrar).
2.   Cardinality of Two – The approach taken in 
draft-ietf-regext-epp-eai-17, where the server (registry) supports an 
alternative email element during a transition period that requires one email 
element to be ASCII.  There are two sub-options based on the recent discussion:
a.   Alternative Email can be ASCII or SMTPUTF8
b.   Alternative Email is only ASCII
My preference is Cardinality of One that would roll back to 
draft-ietf-regext-epp-eai-16.  Please respond to the mailing list with your 
preference or any other options that should be considered.
Thanks,

--

JG

[Image]

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

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

Verisign.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-regext-brown-epp-ttl-04.txt

[Gavin Brown]

Hi Hugo,

I’ll be honest and admit that I hadn’t considered servers that use the host 
attribute model, so I appreciate your feedback.

My (probably quite prejudiced) view is that if an EPP server uses the host 
attribute model, then a TTL value set for a domain should also apply to 
in-bailiwick hosts that are attributes of that object. Almost by definition, if 
a host is merely an attribute of a domain, then it should not have additional 
properties that can be specified: if that is needed, it should be an object 
instead.

I’m not clear on what proportion of EPP servers use the host attribute model 
(my anecdata is that the object model is nearly universal in the gTLD world but 
the attribute/nsset models are more common in ccTLDs), so I’m also unclear on 
whether the extra work to support the host attribute model is justified.

I’d welcome some raising of hands for operators of host attribute servers who 
would implement this extension if it was modified to accommodate them!

G.

From: Hugo Salgado 
Date: Thursday, 2 March 2023 at 14:46
To: Gavin Brown 
Cc: regext@ietf.org 
Subject: Re: [regext] FW: New Version Notification for 
draft-regext-brown-epp-ttl-04.txt
Hi Gavin! It seems to me that there is a case of use that is not being 
considered, when the NS and their glues are defined as an attribute of the 
domain object, without having a host object. If we consider a create command 
with a domain object like the example 1.1 in RFC5731: ns1.example.net 192.0.2.2 
1080:0:0:0:8:800:200C:417A ns2.example.net then the ttl extension can't 
differentiate between a TTL for the NS RRset and TTLs for the A/ RR glue 
records. If we want to allow different TTLs to be delivered for nameservers and 
glues, an attribute could be added for the ttl:infData element such as 
"rrtype=NS|A|". Thanks, Hugo
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-regext-brown-epp-ttl-04.txt

[Gavin Brown]

Thanks Hugo – I appreciate the wording suggestion, and will incorporate it (and 
an acknowledgement) into the next version.

One comment on the idea of separate TTLs: this would probably require that the 
extension support multiple  elements, something like this:


3600
3600


This is because using syntax like  would make the 
TTL ambiguous for the RR types not listed: it would be better to explicitly 
list the TTL values for each RR type.

G.

From: Hugo Salgado 
Date: Thursday, 9 March 2023 at 16:54
To: Gavin Brown 
Cc: regext@ietf.org 
Subject: Re: [regext] FW: New Version Notification for 
draft-regext-brown-epp-ttl-04.txt
Thank you very much Gavin. I understand your point. I know that we are very few 
ccTLDs that use attributes for hosts, and we could live with the restriction 
that prevents the use of distinct TTLs (in fact, I am not sure if we could, we 
would!) ;) However, the same technique I'm proposing to glues-as-attribute 
could also be used for decoupling the NS and DS records. In the case of a 
rollover it is not necessary to reduce the TTL of the NS, only of the DS. One 
might want different values for the two. And using a technique like an rrtype 
attribute on the ttl:infData element would allow it. But anyway, if that's the 
group decision (once adopted), I think that we should still include that 
reasoning in the document for "protocol completeness". Something like: 4.1. Use 
of TTL values in delegation records EPP servers which implement this extension 
SHOULD use the values provided by EPP clients for the TTL values of NS and DS 
records published in the DNS for domain objects, and A and  records 
published in the DNS for host objects. *In case of a registry that utilizes 
hosts as attributes of a domain object (section 1.1 of RFC5731), the A and  
records can't be individually defined and SHOULD use the same TTL of the domain 
object that contains them.* Thanks! Hugo On 16:59 08/03, Gavin Brown wrote: > 
Hi Hugo, > > I’ll be honest and admit that I hadn’t considered servers that use 
the host attribute model, so I appreciate your feedback. > > My (probably quite 
prejudiced) view is that if an EPP server uses the host attribute model, then a 
TTL value set for a domain should also apply to in-bailiwick hosts that are 
attributes of that object. Almost by definition, if a host is merely an 
attribute of a domain, then it should not have additional properties that can 
be specified: if that is needed, it should be an object instead. > > I’m not 
clear on what proportion of EPP servers use the host attribute model (my 
anecdata is that the object model is nearly universal in the gTLD world but the 
attribute/nsset models are more common in ccTLDs), so I’m also unclear on 
whether the extra work to support the host attribute model is justified. > > 
I’d welcome some raising of hands for operators of host attribute servers who 
would implement this extension if it was modified to accommodate them! > > G. > 
> From: Hugo Salgado > Date: Thursday, 2 March 2023 at 14:46 > To: Gavin Brown 
> Cc: regext@ietf.org > Subject: Re: [regext] FW: New Version Notification for 
draft-regext-brown-epp-ttl-04.txt > Hi Gavin! It seems to me that there is a 
case of use that is not being considered, when the NS and their glues are 
defined as an attribute of the domain object, without having a host object. If 
we consider a create command with a domain object like the example 1.1 in 
RFC5731: ns1.example.net 192.0.2.2 1080:0:0:0:8:800:200C:417A ns2.example.net 
then the ttl extension can't differentiate between a TTL for the NS RRset and 
TTLs for the A/ RR glue records. If we want to allow different TTLs to be 
delivered for nameservers and glues, an attribute could be added for the 
ttl:infData element such as "rrtype=NS|A|". Thanks, Hugo > 
___ > 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] Call for agenda items IETF 116

[Gavin Brown]

Hi Antoin,

I'd like to request a slot to discuss draft-regext-brown-epp-ttl.

I will be remote.

Thanks,

G.

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] FW: New Version Notification for draft-regext-brown-epp-ttl-04.txt

[Gavin Brown]

Hi all,

With thanks to Rick and Jim for their feedback, I’ve uploaded a new version of 
the TTL extension draft, which incorporates their suggestions.

I’ve asked the WG chairs for a slot at IETF116 to present this draft and 
request WG adoption.

Feedback and advice gratefully appreciated!

G.

(forgive HTML email, Outlook no longer provides a way to send in plain text)

From: internet-dra...@ietf.org 
Date: Thursday, 23 February 2023 at 10:41
To: Gavin Brown 
Subject: New Version Notification for draft-regext-brown-epp-ttl-04.txt

A new version of I-D, draft-regext-brown-epp-ttl-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:   draft-regext-brown-epp-ttl
Revision:   04
Title:  Extensible Provisioning Protocol (EPP) mapping for DNS 
Time-To-Live (TTL) values
Document date:  2023-02-22
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-04.txt
Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-regext-brown-epp-ttl-04

Abstract:
   This document describes an extension to the Extensible Provisioning
   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
   (TTL) value for domain name delegation records.




The IETF Secretariat

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Adoption request for draft-regext-brown-epp-ttl

[Gavin Brown]

Greetings,

As the author of the above document, I'd like to ask the chairs to 
consider it for adoption by the REGEXT working group.

Thanks in advance,


Gavin.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fw: New Version Notification for draft-regext-brown-epp-related-objects-00.txt

[Gavin Brown]

Hi all,

Here is the first draft of an EPP extension designed to allow servers to 
include information about "related" objects in responses to  commands.

>From the introduction:

"The EPP  command allows clients to retrieve information (subject to 
authorisation) about objects in the repository. Since EPP operates on a 
strictly per-object basis, and since objects may be related to one another, a 
client may often need to issue multiple  commands in order to retrieve 
the data it needs to carry out its operation. This document describes an 
extension to the  command that allows clients to request the inclusion of 
information about related objects in responses. This allows clients to retrieve 
all the required information about an object in a single round-trip to the 
server."

Feedback welcome!

Regards,


From: internet-dra...@ietf.org 
Sent: 27 March 2023 11:59
To: Gavin Brown 
Subject: New Version Notification for 
draft-regext-brown-epp-related-objects-00.txt


A new version of I-D, draft-regext-brown-epp-related-objects-00.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:   draft-regext-brown-epp-related-objects
Revision:   00
Title:  Extensible Provisioning Protocol (EPP) Extension for Related 
Objects
Document date:  2023-03-27
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-regext-brown-epp-related-objects-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-regext-brown-epp-related-objects/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-related-objects


Abstract:
   This document describes an extension to the Extensible Provisioning
   Protocol (EPP) that allows EPP clients to request the inclusion of
   related objects in responses to  commands.




The IETF Secretariat


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Redacting JSContact uid in RDAP

[Gavin Brown]

Ciao Mario,

Can I propose an alternative?

Since (IIRC) a UID can be a URN, and IANA maintains its own URN namespace, 
could we register a URN that would be used to redact the UID? Something like 
"urn:ietf:params:json:rdap+jscontact:uidRedacted"?

Servers could publish this value in the UID of a jsCard object, and clients 
will have a strong single that the value is redacted.

G.

> Hi folks,
> 
> this is a post to resume the discussion about how to redact JSContact 
> uid in RDAP.
> 
> The goal is to reach consensus or majority on one of the following 
> solutuions:
> 
> 1) Redacting by Empty Value method
> 2) Making uid optional in RDAP and then redacting by Removal method
> 3) Recommending the use of uid values that prevent from correlation 
> (e.g. either randomly generated or nil UUIDs)
> 4) Anything else ?
> 
> 
> Please, express your preference(s).
> 
> Best,
> 
> Mario

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt

[Gavin Brown]

Hi Jim,

>  Upon my first review, I find the extension to be an interesting aggregation 
> concept.  I’m not exactly sure why the client wouldn’t just make separate 
> calls to get the same information.

Yes, it can, but I believe there is some efficiency that can be achieved in 
terms of roundtrips.

>   With that, I have the following feedback:
>  
> • I don’t see the purpose of the  child element of the 
>  element, where the child elements can be directly under the 
>  element.

That choice was purely aesthetic, in that the  element conveys 
semantics in a human readable way.

> • It would be good to include a mapping of the response elements with the 
> command elements, along with an indication of existence or ability to include 
> the information.  Such as including the , , and 
> , , , and  elements as children of the 
>  element with some indication of existence or a disclosure issue. 
>  The objects can be contained under those ro elements.  

Yes, this was something I'd been thinking about. At the moment the related 
objects are included "naked", but I had been thinking about something like this:


...



Where an object cannot be included, then the  would be empty but 
would have "code" and "msg" attributes that would mirror the values that the 
client would see if they did an  command on the same object.

G.

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt

[Gavin Brown]

>  Just gave an initial read.  I’m not quite sure of the use-case that would 
> motivate this, other than trying to eliminate round-trips.  But maybe that’s 
> the point. :-)

Yes, that's the point. It's not atypical for a registrar to have to perform 6 
or more  commands in order to retrieve all the relevant information about 
a domain name (registrant/admin/tech/billing contact objects, 2 or more 
nameservers). This extension allows all that information to be retrieved in a 
single command/response transaction. Obviously this is less of an issue for a 
thin registry.

I may be barking up the wrong tree here, so would appreciate feedback from 
registrars as to whether this extension would be helpful (if sufficiently 
deployed by registries).

>  One bit of initial feedback:  In section 3, I was expecting to see “MUST” in 
> this sentence:
>  “When determining whether to include a related object in the  
> element, servers SHOULD apply the same access control rules that are used to 
> determine whether a client is authorised to perform an  on those 
> objects.”  I don’t understand why the protocol would allow the server to use 
> different access rules for the same data accessed via a different path.

Agreed - will fix.

G.

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Gavin Brown]

Hi Patrick,

On Tue, 25 Apr 2023 18:41:26 -0500 Patrick Mevzek wrote:

> Two (+1) quick points on the content for draft version 4.
> 
> Section 8.1 uses twice the same XML namespace for both cases. I suspect 
> `:schema:` is missing in the second one.

Thanks, this is fixed.

> As for TTL values:
> 
>   
>   
> 
> 
> The highest bound should be instead 2147483647 seconds.

Also fixed.

> Alternatively, personally, I would prefer the value to be given as XML type 
> of "duration".
> This allows to still pass it as seconds for those that prefer that, but also 
> allows to pass it in more human friendly formats such as number of minutes, 
> hours, days, etc.
> It does make however stating the maximum value possible more complicated I 
> guess, so maybe not worth doing?

It looks like duration types support the minInclusive and maxInclusive 
attributes, but there is an issue that a duration such as "P1M" can be between 
2,419,200 seconds and 2,678,400 seconds, depending on when the duration is 
converted into an integer. Durations are always relative to a particular date 
and time and don't represent absolute values. Using an non-negative integer 
seems safer to me.

> Also, not sure if a single TTL value for everything is enough.
> Are we sure that all registries will be fine using the same TTL for
> both NS/A/ and DS?
> If I take `.com` right now, NS has 2 days of TTL, where DS only one day.

This is one of the open issues that I would welcome WG input on. Should we 
allow multiple  elements, with an attribute containing a list of DNS 
record types to disambiguate?


172800
86400
3600


It's not inconceivable that some future extension to the DNS will allow 
additional records to be published in parent zones for child zones, so can we 
hard-code the list of record types, or allow any type?

G.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-04.txt

[Gavin Brown]

Hi Rick,

On Thu, 30 Mar 2023, at 22:55, Rick Wilhelm wrote:
> Two points in this email:
>  • one related to the on a comment that I made at the mic during the 30 
> March meeting at IETF 116; and
>  • one higher level issue that came up during Yet Another Read of the 
> draft
> 
> Point One:
> 
> Section 5:  Not sure about whether paragraph 3 of section 5 should have 
> a SHOULD about notifying the sponsoring client with a change poll.   In 
> my experience, change polls are processed inconsistently.  Suggestion:  
> change the SHOULD in Section 5 to a MAY.  (Here is the text so one 
> doesn’t need to go searching)
> 
> *   If a TTL value is changed out-of-band, EPP server operators SHOULD*
> *   notify the sponsoring client using the EPP Change Poll extension*
> *   ([RFC8590]).*

Agreed - I have updated the working document and this will be in the next 
revision.

> Point Two:
> 
> (Note that this next point is one that I would have discussed w/ Gavin 
> in the hallway or over some ramen.)
> 
> This is higher-level issue:  Presently the EPP model is what I will term:
> Opaque Server Control:
>  • server controls the RR TTL values
>  • client has no EPP access to the TTL info (read or write)
> 
> The extension described enables a model that looks like client control:
> Client Control Model:
>  • client can control the RR TTL values
>  • client has EPP access to the TTL info (read and write)
> 
> It seems like the extension should also more clearly enable models of:
> Visible Server Control Model:
>  • server controls the RR TTL values
>  • client has EPP access to the TTL info (read but no write)
> Hybrid Control Model:
>  • server mostly controls the RR TTL values
>  • client has access to the TTL info (read and some write)
> 
> (Note:  I just made up these terms up to help be descriptive, I’m not 
> necessarily proposing that they need to be part of the doc, but having 
> terminology did help me to think about this.)
> 
> To be fair, the doc does have text which allude to these models other 
> than the current.  For example, also in Section 5, we see an allusion 
> to what might be the Hybrid  Control Model:
> 
> *   EPP server operators MAY, in order to address operational or security*
> *   issues, make changes to TTL values out-of-band (that is, not in*
> *   response to an  command received from the sponsoring client).*
> 
> *   Additionally, server operators MAY implement an automatic reset of*
> *   TTL values, so that they may be changed for a finite period before*
> *   and after a planned change, and then revert to a standard value.*
> 
> But the wording of this implies that it’s optional, and that the 
> default state described by the doc is Client Control Model.
> 
> That is, I couldn’t see text in the  command that enabled the 
> Visible Server Control Model (e.g. rejected update commands based on 
> access policy, even for a sponsored object).
> 
> I think that including changes which explicitly enable these different 
> models makes the extension “more mechanism, less policy” and could 
> improve both adoption and transition.

There is a paragraph at the top of Section 4 of the current revision which says 
that servers can reject TTLs that are outside of their policy. However the 
response code it suggests is wrong - it should be 2306 - and would be more 
impactful if placed within the  and  sections. I have made 
these changes which will be in the next revision.

My intention has always been to aim for the extension to follow something like 
the "hybrid control" model that you describe, with a wide range of possible 
configurations, since the "client control" and "server control" models are 
really just the degenerate cases of a hybrid model. I've added some wording to 
the introduction and to Sections 5 and 6 to try to make this clearer.

G.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Thoughts on the fundamental premise of JSContact

[Gavin Brown]

Hi Andy,

I made the original proposal to replace jCard, with a straight mapping of 
RFC5733 contact objects into JSON, back in 2019:

https://mailarchive.ietf.org/arch/msg/regext/bZA9yGAdy2fPaDxiMuMr5CE-z74/

A certain Mr Newton (perhaps you know him) raised the point that this would 
exclude non-EPP based implementers such as RIRs. Shortly afterwards, the first 
JSContact draft was published, which I suggested could be the solution, which 
is why it was subsequently adopted.

It must be said that JSContact evolved quite a bit since the first draft, and 
many of the features which made it attractive as a developer have been lost as 
it has been developed.

Speaking as Mario's largely silent co-author, I am not wedded to JSContact, I 
just want to replace jCard with a sane way of representing contact data in RDAP 
responses. JSContact seemed like it was the most likely thing to achieve that 
back then, but it may not be now.

G.

On Wed, 07 June 2023 18:26 UTC, Andrew Newton  wrote:

> Hi All,
> 
> Very recently I have had the displeasure of implementing jCard for an
> RDAP client, and in so doing have taken a closer look at JSContact and
> have talked to a few people privately about it. Both I and they
> believed that JSContact would be much better than jCard. However,
> after looking at the JSContact spec, I don’t believe it is better and
> in some ways it is far more problematic. Therefore, I want to share my
> thoughts for discussion purposes.
> 
> #1 JSContact uses JSON objects and is therefore better than jCard.
> 
> Both I and a few people with whom I have discussed this issue have
> held this thought. It is true that JSContact uses JSON objects instead
> of the nested arrays found in jCard, but it does not use them in a way
> that makes JSContact easier to handle. Let me explain.
> 
> Most of RDAP is straightforward JSON as would be found in very typical
> REST APIs. This makes serializing and deserializing JSON to and from
> data structures easy in most programming languages using well-known
> toolkits. I offer the following Java example, but these things exist
> in most programming languages:
> 
> public class Link {
> private String href;
> private String value;
> @JsonProperty("type")
> private String mediaType;
> }
> 
> Here, an RDAP link structure is represented. Some of the properties
> can be automatically serialized/deserialized and others are easy to
> use with simple annotations.
> 
> By contrast, JSContact JSON objects are much more than simple JSON
> objects as found in RDAP. Here is an example of JSContact person
> titles:
> 
> "titles": {
>   "le9": {
> "kind": "title",
> "name": "Research Scientist"
>   },
>   "k2": {
> "kind": "role",
> "name": "Project Leader"
>   }
> }
> 
> What should be an array of strings (e.g. “List titles”) is
> instead an object of objects, where each nested object has meta-data
> and is given a unique property name thus requiring the implementer to
> manually map the nested objects. There are even more complicated
> examples, such as the “name” object where given, middle, and sur names
> can be intermingled in sub-objects. IMHO, JSContact makes the same
> mistake of jCard but in the opposite way: where  jCard has arrays that
> should be objects, JSContact has objects that should be arrays.
> 
> #2 Patch Objects
> 
> JSContact has PatchObjects, which are a means of “patching” parts of
> JSContact with other parts of JSContact. The only example of it in the
> I-D is for use in postal address localization, which IMHO is an
> extremely overly-complicated approach to the problem. This mechanism
> is not simple for server implementers and will be very troublesome for
> client implementers.
> 
> PatchObjects will also cause havoc with RDAP redaction, as far as I
> can see. Are the patches created before or after redaction processing?
> Are the patches themselves redactable?
> 
> #3 JSContact Implementations and Scope
> 
> I did a little hunting around for implementations of JSContact, and I
> could only find one. While that is the same number of jCard
> implementations I found, I would have hoped for many more in many
> different programming languages. As it stands, any implementer of
> JSContact for a server or a client will need to be intimate with the
> complexities of JSContact just as they have had to do with jCard.
> 
> This is important because both jCard and JSContact can express contact
> information far in excess of what is found in the RDAP ecosystem, such
> as photos and birthdays and anniversaries. For a developer
> implementing a client, consulting the IANA RDAP extensions registry
> helps to understand the scope of the work necessary but that does not
> help with either jCard or JSContact. What of the many, many items in
> either does an RDAP client implementer not have to implement? There is
> no answer.
> 
> Path-forward #A: SimpleContact
> 
> Up until the WEIRDS wg was encouraged by the IETF to “eat its own
> 

[regext] Fwd: New Version Notification for draft-ietf-regext-epp-ttl-01.txt

[Gavin Brown]

FYI

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-regext-epp-ttl-01.txt
Date: 1 August 2023 at 12:58:25 BST
To: "Gavin Brown" 

[You don't often get email from internet-dra...@ietf.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

A new version of I-D, draft-ietf-regext-epp-ttl-01.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:   draft-ietf-regext-epp-ttl
Revision:   01
Title:  Extensible Provisioning Protocol (EPP) mapping for DNS 
Time-To-Live (TTL) values
Document date:  2023-08-01
Group:  regext
Pages:  16
URL:https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-01

Abstract:
  This document describes an extension to the Extensible Provisioning
  Protocol (EPP) that allows EPP clients to manage the Time-To-Live
  (TTL) value for domain name delegation records.

About this draft

  This note is to be removed before publishing as an RFC.

  The source for this draft, and an issue tracker, may can be found at
  https://github.com/gbxyz/epp-ttl-extension.




The IETF Secretariat



--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-epp-ttl Feedback

[Gavin Brown]

Thanks for the feedback Jim. I agree with all your points and have incorporated 
them into the draft.

Now that the datatracker is open again I am going to submit a new version of 
the draft. The version after that will allow TTLs to be specified for different 
RR types, which is (IIRC) the only outstanding item for this document.

I also need a document shepherd. Any volunteers?

Thanks,

> On 25 Jul 2023, at 17:05, Gould, James  wrote:
> 
> Gavin,
>  Ahead of the REGEXT meeting, I did a fresh review of 
> draft-ietf-regext-epp-ttl and below is my feedback:
>  
> • Section 2 "Extension elements"
> • Nit - "(b) in  and  commands, that the client 
> wishes to remove a previously set value, in favour of the default value.".  I 
> would revise this to "(b) in  and  commands, that the client 
> wishes to use the server default value.". 
> • Nit – “Note that this does no mean…” needs to be “Note that this 
> does not mean…"
> • Section 3.1.1 "EPP  command"
> • The assumption is that the server will only include the 
>  element if the "urn:ietf:params:xml:ns:ttl-1.0" is included in 
> the login services.  The sentence "The  response MAY contain an 
>  element, which MAY contain a  element based on 
> server policy and based on inclusion of "urn:ietf:params:xml:ns:ttl-1.0" in 
> the login service extensions."  Should this be a MUST for the server to 
> always include the  element in the info response based on 
> inclusion of "urn:ietf:params:xml:ns:ttl-1.0" in the login service extensions 
> or does the info command need to be extended to allow the client to 
> explicitly request the ttl extension (e.g.,  element)?
> • Section 4.2 "Relationship between host object and domain object TTL 
> values"
> • I believe the following sentence "However, if no TTL value is 
> specified for a subordinate host object, but a TTL value is specified for the 
> superordinate domain object, then the domain object's TTL value SHOULD be 
> used for the host object instead of the default TTL value." should be a MAY.  
> I'm concerned about the cascading relationship issue of the parent domain and 
> its child hosts.  I don't want a domain update to result in a cascade update 
> to all child hosts or cascading it from the parent domain in the DNS 
> propagating or DNS resolution.
> • Section 4.3 "Use of TTL values for IDN variants"
> • I believe the following sentence "If a domain name has variants 
> ([RFC6927]) that are linked to that domain, then any NS or DNAME records 
> published for those variants SHOULD use the same TTL as that used for the 
> primary domain." should be a MAY.  The concept of a primary and variant 
> domain names and the inheritance of related domain attributes is heavily 
> dependent on the relationship model (associated, aggregated, and composite).  
> I would not have the TTL extension imply a certain kind of relationship 
> model, so this should be a MAY and not a SHOULD.  
> • Section 6.2 "When the TTL should be changed"
> • Nit – The “Client implementations of this specification…” sentence 
> could be changed to "Client implementations of this specification SHOULD 
> ensure that the user understands that changes to a TTL are only effective in 
> shortening transition periods if implemented in a period of time — at least 
> equal to the current TTL — before the planned change."
>     • Section 8.2 "EPP extension registry"
> • Nit - Change Document Status from "Experimental" to "Standards 
> Track"
>  Thanks,
>  -- 
>  JG
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com


--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-epp-ttl Feedback

[Gavin Brown]

Thanks Andy! WG chairs, please note.

G. 

> On 1 Aug 2023, at 13:41, Andrew Newton  wrote:
> 
> [You don't often get email from a...@hxr.us. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Tue, Aug 1, 2023 at 7:49 AM Gavin Brown  wrote:
>> I also need a document shepherd. Any volunteers?
> 
> I can do it.
> 
> -andy

--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: New Version Notification for draft-ietf-regext-epp-ttl-00.txt

[Gavin Brown]

Hi all,

My thanks to those who supported adoption of this document. As requested I have 
published a -00 under the new name.

I have a few updates to make that I need to port over from the previous 
version, then I'll publish a -01.

I need a document shepherd, are there any volunteers?

Thanks in advance,

G.

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-regext-epp-ttl-00.txt
Date: 16 May 2023 at 13:32:40 BST
To: "Gavin Brown" 

[You don't often get email from internet-dra...@ietf.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

A new version of I-D, draft-ietf-regext-epp-ttl-00.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:   draft-ietf-regext-epp-ttl
Revision:   00
Title:  Extensible Provisioning Protocol (EPP) mapping for DNS 
Time-To-Live (TTL) values
Document date:  2023-05-16
Group:  regext
Pages:  15
URL:https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl


Abstract:
  This document describes an extension to the Extensible Provisioning
  Protocol (EPP) that allows EPP clients to manage the Time-To-Live
  (TTL) value for domain name delegation records.




The IETF Secretariat



--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

[Gavin Brown]

Thanks Hugo, this will be fixed.

> On 31 Jan 2024, at 15:41, Hugo Salgado  wrote:
> 
> Dear Gavin.
> One of the errors that I indicated in a previous email for version 04
> is still in this version:
> 
> - in 1.2.1 second point, and in 1.2.1.2 second paragraph, the reference
>  to "Section 1.3 of [RFC6895]" for the record type format is wrong.
>  There's no 1.3 section. I think you mean 3.1.
> 
> Thanks!
> 
> Hugo Salgado
> 
> On 06:24 26/01, internet-dra...@ietf.org wrote:
>> Internet-Draft draft-ietf-regext-epp-ttl-05.txt is now available. It is a 
>> work
>> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
>> 
>>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
>> Time-To-Live (TTL) values
>>   Author:  Gavin Brown
>>   Name:draft-ietf-regext-epp-ttl-05.txt
>>   Pages:   26
>>   Dates:   2024-01-26
>> 
>> Abstract:
>> 
>>   This document describes an extension to the Extensible Provisioning
>>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>>   (TTL) value for domain name delegation records.
>> 
>> About this draft
>> 
>>   This note is to be removed before publishing as an RFC.
>> 
>>   The source for this draft, and an issue tracker, may can be found at
>>   
>> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6qWZByhj$
>>  [github[.]com].
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6jjj06dL$
>>  [datatracker[.]ietf[.]org]
>> 
>> There is also an HTMLized version available at:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-05__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6gLWO85j$
>>  [datatracker[.]ietf[.]org]
>> 
>> A diff from the previous version is available at:
>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-05__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6mw5niLK$
>>  [author-tools[.]ietf[.]org]
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> regext mailing list
>> regext@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6ow5fqHE$
>>  [ietf[.]org]
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!50YgRwLOFN19X4gYTVPEJzb0_pP4U5aRYpjZH97XUHH-tpOHWYwFGVatK9kG26EbcsEh-nfZgAOWJFZaT4pm6ow5fqHE$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

[Gavin Brown]

Hi Jim,

Thanks for this feedback.

Am I correct in saying that in your view, if a server receives an unextended 
 command (on a session where the TTL extension was included in an 
 element in the  frame) then the  response should not 
include the  element in the response?

If that's the case, then this seems somewhat at variance with the approach 
taken historically: for example, one does not need to extend the  command 
to get the  and  elements in the  response.

Are there examples of more recent extensions which require an extension to an 
 command to get an extended  response? I would not consider the 
launch extensions here for example, since it requires the client to provide 
parameters in order to satisfy the request.

Thanks,

Gavin.


> On 31 Jan 2024, at 15:29, Gould, James  wrote:
> 
> Gavin,
> 
> Thanks for making the updates to draft-ietf-regext-epp-ttl-05.  I did find 
> one issue with the XML schema, where  required="true"/> needs to be  use="required"/>.  I would prefer making the "policy" attribute optional with 
> a default value of "false", as in:
> 
> 
> 
> I would then change the description in section 1.3 to be:
> 
> It has a single OPTIONAL "policy" attribute, which takes a boolean value with 
> a default value of "false".  
> 
> If a server receives an  command for a domain or host object which 
> includes a  element with a "policy" attribute that is "1" (or 
> "true"), then the response MUST include  records for all supported 
> DNS record types with the "min", "default" and "max" policy attributes, 
> irrespective of whether those record types are in use by the object.  If a 
> server receives an  command for a domain or host object which includes 
> a  element with a "policy" attribute that is "0" (or "false"), then 
> the response MUST include  records for all DNS record types that are 
> in use by the object without the "min", "default" and "max" policy attributes.
> 
> In additional in section 2.1.1:
> 
> If the command contained a  element with a policy "attribute" with 
> a "1" (or "true") value, then the  element MUST contain a 
>  element for each supported DNS record type, and those elements MUST 
> have the "min", "default" and "max" policy attributes, as described in 
> Section 1.3.  Otherwise, the response MUST contain a  element for 
> each DNS record type that is in use by the object without the "min", 
> "default", and "max" policy attributes.  
> 
> Section 2.1.1 may be a duplicate of the description in section 1.3, but I 
> believe that's ok.
> 
> Thanks,
> 
> -- 
> 
> JG 
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!-BmVcm0DEP6Pd-hbhf62oVe9EE2m7kih1fZlStX43HWhDrmwy1SjkdL_xXt8tVb-XA9EjRFrFp_uEDH_FwTVex-D$
>  [verisigninc[.]com]> 
> 
> 
> 
> 
> On 1/29/24, 7:54 AM, "regext on behalf of Gavin Brown" 
> mailto:regext-boun...@ietf.org> on behalf of 
> gavin.br...@icann.org <mailto:gavin.br...@icann.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. 
> 
> 
> Hi all,
> 
> 
> This version updates the extension with Jim's feedback, so that the 
> min/default/max attributes on  elements are only included in  
> responses if the client includes  in the command.
> 
> 
> I haven't received much feedback other than Jim's, so apart from fixing any 
> minor issues that may be found and reported, I think this document may be 
> ready for WGLC, although I am expecting the DNS Directorate may have some 
> suggestions.
> 
> 
> If you have implemented this extension in a client or server, please let me 
> know so I can details to the "Implementation Status" section of the draft. I 
> am in the process of adding support to Pepper[1], after which we'll have two 
> independent implementations which IIRC is the preferred minimum number.
> 
> 
> So if you have feedback, speak now or lose your right to say "I told you so" 
> in future :)
> 
> 
> G.
> 
> 
> [1] 
> https://urldefense.com/v3/__https://secure-web.cisco.com/1gdFbL5nCWZzt1mOR7uORNvem-z-ecFM8xhNd4Rn8UGX_SSlBZYbwjWk2HLj3nFghtZHtS_5D9sQ7vh92HPIvgMmXmaqw6izeZ-mlerR8gYBR1a7rmgg6NSVd0FYEs_kkbBrCKCdZh_bdO-4a

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-04.txt

[Gavin Brown]

Greetings all,

I have just uploaded draft-ietf-regext-epp-ttl-04.

Notable changes in this version:

* The "for" attribute is now an enumeration, and can take the following values: 
NS, DS, DNAME, A, , custom.

* If the "for" attribute is "custom", then the "custom" attribute can be used 
to specify a DNS record type other than those above. However, it still has to 
match the regular expression from RFC 6895 and still has to be registered with 
IANA.

*  elements - in responses only - must have the "min", "default" and "max" 
attributes. I'm open to feedback about making them mandatory but I think they 
are so useful to clients that there would have to be a pretty compelling reason 
to remove the "required" XSD property.

This version also closes off the backlog of changes I had planned, so unless 
the WG has more feedback, I think this draft is basically done from a 
functional perspective I will however require to complete the Implementation 
Status section to get to the RFC publication stage.

Thanks,

> On 14 Dec 2023, at 17:06, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-04.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-04.txt
>   Pages:   21
>   Dates:   2023-12-14
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   https://github.com/gbxyz/epp-ttl-extension
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-04
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-04
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-03.txt

[Gavin Brown]

Hi Jim, thanks for your feedback. My comments are below.

> On 22 Nov 2023, at 19:43, Gould, James  wrote:
> 
> Gavin,
>  Thank you for posting draft-ietf-regext-epp-ttl-03.  Below is my review 
> feedback:
>  
> • Section 1.2 “Extension elements”
> • Nit – I would change “It has a single REQUIRED attribute, for, 
> which specifies the DNS record type to which the TTL value pertains” to “It 
> has a single REQUIRED “for” attribute, which specifies the DNS record type to 
> which the TTL value pertains”.

This will be fixed in the next version.

> • Section 1.2.2 “Supported DNS record types”
> • Nit – Put the “for” attribute in double quotes, such as “that can 
> be included in the “for” attribute.

As above.

> • How would setting the A and  TTLs be implemented for servers 
> that implement the host objects model of RFC 5732?

I believe this is adequately addressed in the draft, but the structure of the 
document does not clearly signpost it. So the next version will have a  
specific section on glue records which will combine the last bullet point in 
the list in section 1.2.2 with the paragraph that immediately follows it. The 
subsequent two paragraphs will be moved to a new subsection in Section 5.

> • Section 3.2 “Use of TTL values for IDN variants”
> • I believe this section needs to be removed, since it implies a 
> specific form of IDN variant relationship that should be defined outside of 
> the TTL extension.  The sharing of attributes across a parent domain and the 
> variants, including TTL settings, should be covered by the IDN variant 
> specification and not the TTL extension itself.

Agreed, this section has been removed.

> • Section 5.2 “When TTL values should be changed”
> • What does the convention of the use of the underbars in “_before_” 
> indicate?  My recommendation is to remove the underbars or describe the 
> convention in section 1.1 “Conventions used in this document”.

You're looking at the plaintext rendering, but in the HTML rendering, "before" 
is shown with emphasis, that is, italics. This is to emphasise that the TTL 
value must be changed before the RDATA value if the operator wants the shorter 
TTL to be in effect before the RDATA is changed.

> • General considerations
> • Inclusion of the server default TTL in the info response would be 
> helpful.
> i. Could be included in a policy response based on inclusion of a 
> policy option in the command.
> • Inclusion of the server min and max TTL in the info response would 
> be helpful
> i. Could be included in a policy response based on inclusion of a 
> policy option in the command.

So I think I would approach this by adding three attributes to :

* min - the minimum value
* default - the default value
* max - the maximum value

Servers would then include these in responses to  commands, .e.g:


  
  


I'd appreciate the WG's feedback on this before I commit pen to paper. For 
example, should these attributes be optional, or mandatory in server responses? 
I am minded to make them mandatory, but would appreciate feedback from server 
operators.

> • The known set of RRecs could be enumerated with support for 
> extensibility, like what was done with the use of the "custom" enumerated 
> value and the custom string value in RFC 8334[datatracker.ietf.org] for the 
> launch phases and "custom" command enumerated value with the "customName" 
> attribute in RFC 8748 [datatracker.ietf.org].
> i. Providing a predefined enumeration list supports XML parser 
> validation by default and supports extensibility for new values for the 
> future.

This makes sense to me so I will implement it in the next version.

Thanks,

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] TTL extension for RDAP

[Gavin Brown]

Hi all,

As a complement to the EPP extension, I've just uploaded a first draft of an 
RDAP extension:

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

This extension does not require the use of the EPP extension: it can be used by 
any RDAP server operator wishing to publish TTL information in RDAP responses.

Given bandwidth constraints, I would not seek WG adoption until the EPP 
document is published as an RFC, but wanted to publish an early draft for 
review. Feedback welcome!

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] TTL extension for RDAP

[Gavin Brown]

Hi Jim,

> On 2 Jan 2024, at 14:52, Gould, James  wrote:
> 
> Gavin,
> 
> I question the need for a TTL RDAP extension, since the TTLs are easily 
> assessable in DNS to the public.  The management of the TTLs is provisioned 
> in EPP via the TTL EPP extension and can be made available to the registrant 
> by the registrar.  There are examples of DNS information duplicated in RDAP, 
> such as the DNSSEC information in RFC 9083, but I'm concerned with setting 
> the pattern of duplicating additional DNS information with no perceived value.
> 

RDAP domain objects contain other information that can also be obtained in the 
DNS, such as nameservers, glue, and DS records. Evidently there is value in 
providing this information via an alternate channel (such as to debug DNS 
resolution issues). Providing TTL information via RDAP is consistent with that 
approach and will also be helpful in the same scenarios.

G.

> Thanks,
> 
> -- 
> 
> JG 
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!-twuq17rqSKX-pCKHkTFhmzOXZaiQ1nbrzbWhB81AVnwvlHzeutZfLJ89yfRnjIyun6gaZT9bPAZBBwW9FcwU_pM$
>  [verisigninc[.]com]> 
> 
> 
> 
> 
> On 1/2/24, 9:03 AM, "regext on behalf of Gavin Brown" 
> mailto:regext-boun...@ietf.org> on behalf of 
> gavin.br...@icann.org <mailto:gavin.br...@icann.org>> wrote:
> 
> 
> 
> Hi all,
> 
> 
> As a complement to the EPP extension, I've just uploaded a first draft of an 
> RDAP extension:
> 
> 
> https://urldefense.com/v3/__https://secure-web.cisco.com/1cbpvLaxkXtiMxQku8jDm2TgXvD6OlaLPfyuDyqcKICKKvoZdwaB4a-dn4H9lpfSVFKLTxRsg8H1QbTOnAYaSDJhRJc-Nej9fgazwK0PO2MWTfIZlWiACP7SIWz5WocpqC4fi3lZlo5w7y47KB2rh2vo-xSZwzoAIEvQtKrCXy9D4MMUPMwwHI2YaYxWKqyLcsEiRiVGw0TiYcU4viI_CRckheWvm9Kdzy1y10JrHdN_aHYu06YXF606kW3ME8bi2c6QoApNmUGIZRUFmKaXxD9LTcon-6ARcRBgf_afSZas/https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-brown-rdap-ttl-extension*2F__;JSUlJSUl!!PtGJab4!-twuq17rqSKX-pCKHkTFhmzOXZaiQ1nbrzbWhB81AVnwvlHzeutZfLJ89yfRnjIyun6gaZT9bPAZBBwW9Kx0b62K$
>  [secure-web[.]cisco[.]com] 
> <https://urldefense.com/v3/__https://secure-web.cisco.com/1cbpvLaxkXtiMxQku8jDm2TgXvD6OlaLPfyuDyqcKICKKvoZdwaB4a-dn4H9lpfSVFKLTxRsg8H1QbTOnAYaSDJhRJc-Nej9fgazwK0PO2MWTfIZlWiACP7SIWz5WocpqC4fi3lZlo5w7y47KB2rh2vo-xSZwzoAIEvQtKrCXy9D4MMUPMwwHI2YaYxWKqyLcsEiRiVGw0TiYcU4viI_CRckheWvm9Kdzy1y10JrHdN_aHYu06YXF606kW3ME8bi2c6QoApNmUGIZRUFmKaXxD9LTcon-6ARcRBgf_afSZas/https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-brown-rdap-ttl-extension*2F__;JSUlJSUl!!PtGJab4!-twuq17rqSKX-pCKHkTFhmzOXZaiQ1nbrzbWhB81AVnwvlHzeutZfLJ89yfRnjIyun6gaZT9bPAZBBwW9Kx0b62K$
>  [secure-web[.]cisco[.]com]>
> 
> 
> This extension does not require the use of the EPP extension: it can be used 
> by any RDAP server operator wishing to publish TTL information in RDAP 
> responses.
> 
> 
> Given bandwidth constraints, I would not seek WG adoption until the EPP 
> document is published as an RFC, but wanted to publish an early draft for 
> review. Feedback welcome!
> 
> 
> G.
> 
> 
> --
> Gavin Brown
> Principal Engineer, Global Domains & Strategy
> Internet Corporation for Assigned Names and Numbers (ICANN)
> 
> 
> https://urldefense.com/v3/__https://secure-web.cisco.com/15sz32WNlSqbvdDNG-36T1VGWZDQS4oBVAEwgLa2qHna_Z6fAkHckEVLZG3WQtX7iVKHwZjjG059vJPzOG-dhenzj6zwBOavJ9GQUkhcFzy2U6eS2Uqw0_e_nmwSXS-xOWUZt_xdYJO5HKUUQ2eJ0MR2S_iWsoirMKWeFkS9EoFd3INxIzDaUC7ZsiCCNfbWpb3d-zacRh7gA53UDTnJ0u1COR0lzOoSzPVyZLZMXlUzI4hXpf8XRryhe2BjRPmMhwq5lWNw3kePM7NYMeFo-50zYlcqG094WfTDzQnR9fzI/https*3A*2F*2Fwww.icann.org__;JSUl!!PtGJab4!-twuq17rqSKX-pCKHkTFhmzOXZaiQ1nbrzbWhB81AVnwvlHzeutZfLJ89yfRnjIyun6gaZT9bPAZBBwW9ICJXPCI$
>  [secure-web[.]cisco[.]com] 
> <https://urldefense.com/v3/__https://secure-web.cisco.com/15sz32WNlSqbvdDNG-36T1VGWZDQS4oBVAEwgLa2qHna_Z6fAkHckEVLZG3WQtX7iVKHwZjjG059vJPzOG-dhenzj6zwBOavJ9GQUkhcFzy2U6eS2Uqw0_e_nmwSXS-xOWUZt_xdYJO5HKUUQ2eJ0MR2S_iWsoirMKWeFkS9EoFd3INxIzDaUC7ZsiCCNfbWpb3d-zacRh7gA53UDTnJ0u1COR0lzOoSzPVyZLZMXlUzI4hXpf8XRryhe2BjRPmMhwq5lWNw3kePM7NYMeFo-50zYlcqG094WfTDzQnR9fzI/https*3A*2F*2Fwww.icann.org__;JSUl!!PtGJab4!-twuq17rqSKX-pCKHkTFhmzOXZaiQ1nbrzbWhB81AVnwvlHzeutZfLJ89yfRnjIyun6gaZT9bPAZBBwW9ICJXPCI$
>  [secure-web[.]cisco[.]com]>
> 
> 
> ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://urldefense.com/v3/__https://secure-web.cisco.com/1zDwYvCDqp8Pe87NHBav-VwKLD4OsQaYPVOW-QDt8_XqhAkoE0SCfc6SgIgcQhFAiYdPpEexfvZm-uUkC2yh0heIAL8jzcbiv9zv15IQnZMrwgGCMLn4E8lEelydzsbpdLXVvWFZ5KZ04pt7LRwQ54UeErCPQPqpMNHur_I8qeQIRxM7v-k93VUM9rBlpu_82laTay05HjVdCAVt

Re: [regext] [Ext] TTL extension for RDAP

[Gavin Brown]

Hi Andy,

> On 3 Jan 2024, at 15:12, Andrew Newton  wrote:
> 
> Given that the TTL can be updated independently of the domain name,
> there is utility in exposing TTLs in RDAP especially if that
> information can be given with the events & links as is done with the
> DNSSEC data in RDAP. I know I have had times in the past when I needed
> to know when a TTL was last changed.

Do you think the ttl_values object needs an events array then?

To support this I would change the ttl_values object as follows:

"ttl": {
"values": {
"NS": 3600,
"DS": 60,
},
"events": [
{
"eventAction": "lastChanged",
"eventDate": "2012-07-23T05:15:47Z",
"eventActor": "registry-operator"
}
]
}

G.

> 
> Here is the example from 9083:
> 
> "secureDNS":
>  {
> 
> "zoneSigned": true,
> "delegationSigned": true,
> "maxSigLife": 604800,
> "keyData":
> [
>   {
> "flags": 257,
> "protocol": 3,
> "algorithm": 8,
> "publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
> "events":
> [
>   {
> "eventAction": "last changed",
> "eventDate": "2012-07-23T05:15:47Z"
>   }
> ]
>   }
> ]
>  }
> 
> -andy
> 
> On Wed, Jan 3, 2024 at 7:17 AM Gould, James
>  wrote:
>> 
>> Gavin,
>> 
>> Agreed that the base RDAP RFCs include DNS information, but in the case of 
>> nameservers they are standard provisioning objects with the host EPP mapping 
>> in RFC 5733 and with additional attributes.  I don't believe that there is 
>> value in replicating DNS information in RDAP that is not related to other 
>> information (e.g., creation date, updated date, transfer date, sponsorship) 
>> that may have value to the public.  My recommendation is to focus management 
>> of TTL in EPP with its impact on DNS and leave RDAP alone.  Let's not go 
>> down the slippery slope of bloating RDAP by replicating DNS information when 
>> there is no perceived value.
>> 
>> --
>> 
>> JG
>> 
>> 
>> 
>> James Gould
>> Fellow Engineer
>> jgo...@verisign.com 
>> 
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com 
>> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!4JeVZIu2TFksUlRg1kqU3iv7m_d4qkDyWccMxJpAmVEjAijvV3KNeAWvThRFn1pZnBMJ8BjKWVtK8DZkFyOV$
>>  [verisigninc[.]com]>
>> 
>> 
>> 
>> 
>> On 1/3/24, 4:44 AM, "Gavin Brown" > <mailto:gavin.br...@icann.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.
>> 
>> 
>> Hi Jim,
>> 
>> 
>>> On 2 Jan 2024, at 14:52, Gould, James >> <mailto:jgo...@verisign.com>> wrote:
>>> 
>>> Gavin,
>>> 
>>> I question the need for a TTL RDAP extension, since the TTLs are easily 
>>> assessable in DNS to the public. The management of the TTLs is provisioned 
>>> in EPP via the TTL EPP extension and can be made available to the 
>>> registrant by the registrar. There are examples of DNS information 
>>> duplicated in RDAP, such as the DNSSEC information in RFC 9083, but I'm 
>>> concerned with setting the pattern of duplicating additional DNS 
>>> information with no perceived value.
>>> 
>> 
>> 
>> RDAP domain objects contain other information that can also be obtained in 
>> the DNS, such as nameservers, glue, and DS records. Evidently there is value 
>> in providing this information via an alternate channel (such as to debug DNS 
>> resolution issues). Providing TTL information via RDAP is consistent with 
>> that approach and will also be helpful in the same scenarios.
>> 
>> 
>> G.
>> 
>> 
>>> Thanks,
>>> 
>>> --
>>> 
>>> JG
>>> 
>>> 
>>> 
>>> James Gould
>>> Fellow Engineer
>>> jgo...@verisign.com <mailto:jgo...@verisign.com> 
>>> >> <mailto:jgo...@verisign.com>>
>>> 
>>> 703-948-3271
>>> 12061 Bluemont Way
>>> Reston, VA 20190
>>> 
>>> Verisign.com 
>>> <https:

Re: [regext] [Ext] TTL extension for RDAP

[Gavin Brown]

Hi Andy,

> On 4 Jan 2024, at 14:22, Andrew Newton  wrote:
> 
> On Wed, Jan 3, 2024 at 10:20 AM Gavin Brown  wrote:
>> 
>> Do you think the ttl_values object needs an events array then?
>> 
>> To support this I would change the ttl_values object as follows:
>> 
>> "ttl": {
>> "values": {
>> "NS": 3600,
>> "DS": 60,
>> },
>> "events": [
>> {
>>"eventAction": "lastChanged",
>>"eventDate": "2012-07-23T05:15:47Z",
>>"eventActor": "registry-operator"
>> }
>> ]
>> }
> 
> I was thinking that "ttl" would be an array of objects, with each
> object containing an array of DNS RR names, a TTL, an array of events
> and an array of links. This keeps it similar to the DNSSEC data. I
> know the links thing seems silly, but it could be used to point to TTL
> policies given some registrars, INRs, etc have TTL policies.

So something like this? I've also thrown in min/default/max values as well:

"ttl": [
{
"types": ["NS", "DELEG"],
"value": 3600,
"min": 60,  // optional
"default": 86400,   // optional
"max": 172800,  // optional
"remarks": [ ... ], // optional
"events": [ ... ]   // optional
},
{
"types": ["DS"],
"value": 3600,
"remarks": [ ... ],
"events": [ ... ]
},
...
],
...

So each RRtype could have a remark which provides the policy (or a link to the 
policy) and some events.

G.

> 
> To address the JG's point, there are registries that are not run by
> EPP (ccTLDs, RIRs) and registrars don't necessarily have to follow the
> EPP data model in their own RDAP servers as far as I know. I think
> this is generally useful and I know there have been times where I need
> to know what a registrar had as a TTL vs what I was seeing in DNS.
> 
> -andy

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] TTL extension for RDAP

[Gavin Brown]

Hi Jim,

> On 3 Jan 2024, at 15:53, Gould, James  wrote:
> 
> Andy, 
> 
> The TTL is an extension to the domain name update, so they are not 
> independent.

The draft explicitly states that TTLs may be changed out-of-band. The Change 
Poll extension is suggested as a way to inform registrars of such changes, but 
there's no way for DNS operators or registrants to be notified of changes, so 
providing this information in RDAP seems useful.

G.

>  The same goes for the DNSSEC extension, where I don't believe the "events" 
> member of the "dsData"member is generally used.  Are there RDAP servers that 
> include "dsData" "events" member that differs from the "domain" "events" 
> member?   
> 
> -- 
> 
> JG 
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com<https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!5GuTiuq9XrUu8aQd2RokjKHNwmwEZ5tlC8tsJDWbNrI3g7ADTmvE53XFAntJcelbNIfCOKE7D95jcQ85rUrhGcd_$
>  [verisigninc[.]com]> 
> 
> 
> 
> 
> On 1/3/24, 10:27 AM, "Andrew Newton" 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. 
> 
> 
> Given that the TTL can be updated independently of the domain name,
> there is utility in exposing TTLs in RDAP especially if that
> information can be given with the events & links as is done with the
> DNSSEC data in RDAP. I know I have had times in the past when I needed
> to know when a TTL was last changed.
> 
> 
> Here is the example from 9083:
> 
> 
> "secureDNS":
> {
> 
> 
> "zoneSigned": true,
> "delegationSigned": true,
> "maxSigLife": 604800,
> "keyData":
> [
> {
> "flags": 257,
> "protocol": 3,
> "algorithm": 8,
> "publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
> "events":
> [
> {
> "eventAction": "last changed",
> "eventDate": "2012-07-23T05:15:47Z"
> }
> ]
> }
> ]
> }
> 
> 
> -andy
> 
> 
> On Wed, Jan 3, 2024 at 7:17 AM Gould, James
> mailto:40verisign@dmarc.ietf.org>> 
> wrote:
>> 
>> Gavin,
>> 
>> Agreed that the base RDAP RFCs include DNS information, but in the case of 
>> nameservers they are standard provisioning objects with the host EPP mapping 
>> in RFC 5733 and with additional attributes. I don't believe that there is 
>> value in replicating DNS information in RDAP that is not related to other 
>> information (e.g., creation date, updated date, transfer date, sponsorship) 
>> that may have value to the public. My recommendation is to focus management 
>> of TTL in EPP with its impact on DNS and leave RDAP alone. Let's not go down 
>> the slippery slope of bloating RDAP by replicating DNS information when 
>> there is no perceived value.
>> 
>> --
>> 
>> JG
>> 
>> 
>> 
>> James Gould
>> Fellow Engineer
>> jgo...@verisign.com <mailto:jgo...@verisign.com> 
>> mailto:jgo...@verisign.com>>
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com 
>> <https://urldefense.com/v3/__http://secure-web.cisco.com/1G5fgdFkXdulNRG5Wp0MVgw1N8i2VEWJQUqwCuJTkvB2kDu268F7-47Eg0aesDAxPh36PrN-BVhPV2ZborUE-FR1IZFEvNJXO8R7Ccnpd9dkn-4xLoRNmcdjvygo-HiW5AILZ210BGYByHPgWFMY_t8bn4rN0Kiie59Tp9nF9VQzp64FkNBUd469D9wtTrM6babIyDlob_xhplmt2cCazwGsgYlGbD8LZCuiW8hPPfGISqINVDEjI4cfTuKnRxbHfDLfhlUrIY1E_uGUQNLS5XNkRNQVAuFoIdFHGMWCy5fY/http*3A*2F*2Fverisigninc.com*2F__;JSUlJQ!!PtGJab4!5GuTiuq9XrUu8aQd2RokjKHNwmwEZ5tlC8tsJDWbNrI3g7ADTmvE53XFAntJcelbNIfCOKE7D95jcQ85rQMSYQoj$
>>  [secure-web[.]cisco[.]com]> 
>> <https://urldefense.com/v3/__http://secure-web.cisco.com/1G5fgdFkXdulNRG5Wp0MVgw1N8i2VEWJQUqwCuJTkvB2kDu268F7-47Eg0aesDAxPh36PrN-BVhPV2ZborUE-FR1IZFEvNJXO8R7Ccnpd9dkn-4xLoRNmcdjvygo-HiW5AILZ210BGYByHPgWFMY_t8bn4rN0Kiie59Tp9nF9VQzp64FkNBUd469D9wtTrM6babIyDlob_xhplmt2cCazwGsgYlGbD8LZCuiW8hPPfGISqINVDEjI4cfTuKnRxbHfDLfhlUrIY1E_uGUQNLS5XNkRNQVAuFoIdFHGMWCy5fY/http*3A*2F*2Fverisigninc.com*2F__;JSUlJQ!!PtGJab4!5GuTiuq9XrUu8aQd2RokjKHNwmwEZ5tlC8tsJDWbNrI3g7ADTmvE53XFAntJcelbNIfCOKE7D95jcQ85rSjWDJ_4$
>>  [secure-web[.]cisco[.]com]>
>> 
>> 
>> 
>> 
>> On 1/3/24, 4:44 AM, "Gavin Brown" > <mailto:gavin.br...@icann.org> 
>> <mailto:gavin.br...@icann.

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-03.txt

[Gavin Brown]

Hi all,

As discussed in Prague, I have uploaded a new version of 
draft-ietf-regext-epp-ttl.

Notable changes:

1. Rolled back the "straw man" syntax from 02. ttl:ttl now has a for
attribute which can be any DNS record type. Section 1.2.2
describes how the set of supported record types may be limited.

2. Removed the global/explicit models and just use the explicit
model.

3. Removed the cascading effect where a TTL set on a domain affects
subordinate hosts.

Many thanks to those who provided feedback, and particular thanks to Ties de 
Kock who resolved my XML schema issue!

G.

> On 22 Nov 2023, at 16:53, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-regext-epp-ttl-03.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-03.txt
>   Pages:   19
>   Dates:   2023-11-22
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-03
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-03
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext


--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org



smime.p7s
Description: S/MIME cryptographic signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Call for agenda items IETF119

[Gavin Brown]

Hi Antoin and Jim,

I would like to present the following:

* draft-ietf-regext-epp-ttl (5 mins should be enough)
* draft-brown-rdap-ttl-extension (5 mins)
* draft-brown-epp-deleg[1] (5-10 mins)

I am happy to yield on the latter two if others need time for their 
presentations. [1] is also being discussed during the DNSOP interim on 
Wednesday.

G.

> On 27 Jan 2024, at 15:08, Antoin Verschuren  
> wrote:
> 
> Hi all,
> 
> It is time to schedule our session for IETF 119 next week.
> Since we had too little time scheduled for IETF 118 where we filled our 
> complete 1,5 hour time slot, we are thinking of requesting 2 hours this time 
> if people come up with enough agenda items.
> We see enough reasons on the list that may justify a longer slot this time, 
> and he chairs also suggested to organise an interim meeting to discuss the 
> negotiation, signalling, and versioning in RDAP, which we unfortunately 
> failed to do due to prolonged and conflicting holiday scheduling over the new 
> year by the chairs, so we may schedule that in Brisbane too.
> 
> So if you already have agenda items, please let the chairs know, so we can 
> justify requesting 2 hours of meeting time in Brisbane.
> 
> Regards,
> 
> Your REGEXT co-chairs Jim and Antoin
> 
> 
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-R8-coMHyTpJs2cx1rrT50_63TuWXTB3nHIfKQZT-qxGeD_MQDL0sxn6nsC7BfXDu3YYIR0MVYZ1LHCS3o62qEyQf9x5I7YfVYD2XIoB$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

[Gavin Brown]

Hi all,

This version updates the extension with Jim's feedback, so that the 
min/default/max attributes on  elements are only included in  
responses if the client includes  in the command.

I haven't received much feedback other than Jim's, so apart from fixing any 
minor issues that may be found and reported, I think this document may be ready 
for WGLC, although I am expecting the DNS Directorate may have some suggestions.

If you have implemented this extension in a client or server, please let me 
know so I can details to the "Implementation Status" section of the draft. I am 
in the process of adding support to Pepper[1], after which we'll have two 
independent implementations which IIRC is the preferred minimum number.

So if you have feedback, speak now or lose your right to say "I told you so" in 
future :)

G.

[1] https://github.com/gbxyz/pepper

> On 26 Jan 2024, at 14:24, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-05.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-05.txt
>   Pages:   26
>   Dates:   2024-01-26
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   
> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC3VaYPVTA$
>  [github[.]com].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC1SM_JvMA$
>  [datatracker[.]ietf[.]org]
> 
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-05__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC0Bw5LmWA$
>  [datatracker[.]ietf[.]org]
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-05__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC0sxk-WpA$
>  [author-tools[.]ietf[.]org]
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC1cKEx7Pw$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp

[Gavin Brown]

+1

> On 29 Jan 2024, at 15:17, Antoin Verschuren  
> wrote:
> 
> This is the formal adoption request for Best Practices for Deletion of Domain 
> and Host Objects in the Extensible Provisioning Protocol (EPP):
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/__;!!PtGJab4!7dxOZoe8bYBaNJP_DKp_IcAGdgyq8aquwGJ-1njwhyjfJrLaaMBKxNZTe5Ouov-EBPHtnX0K-WCeZAtRuujBMRf2yWzsjkgM6OqtuJUZ$
>  [datatracker[.]ietf[.]org]
> 
> 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.
> Andy Newton already volunteered to be a document shepherd this item will be 
> adopted.
> 
> This Call For Adoption will close on Monday 12 February.
> 
> If there are no objections, the chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Jim and Antoin
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!7dxOZoe8bYBaNJP_DKp_IcAGdgyq8aquwGJ-1njwhyjfJrLaaMBKxNZTe5Ouov-EBPHtnX0K-WCeZAtRuujBMRf2yWzsjkgM6P9clGTC$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-04.txt

[Gavin Brown]

Hi Jim, apologies for the delayed response.

> On 20 Dec 2023, at 15:26, Gould, James  
> wrote:
> 
> Gavin,
> 
> Thanks for making the updates in draft-ietf-regext-epp-ttl-04.  I went ahead 
> and implemented draft-ietf-regext-epp-ttl-04 in the Verisign EPP SDK that 
> implements a client and a server.  I did find the following issue:
> 
>   The “commandTTLType“ is missing the optional “custom” attribute from the 
> “commandTTLType”, so the “custom” rrec type cannot be specified in the create 
> and update commands.

I think you meant "responseTTLType" instead of the second "commandTTLType" 
above, but that's a good spot, thanks. Fixed in my working copy.

> I have the following recommendation:
> 
>   I implemented from the full examples included in the draft, so my 
> recommendation is to include the use of the  custom=”DELEG”>3600 in the domain create and domain info response 
> examples to cover all
> elements defined in the XML schema.  Of course, there no method yet to define 
> the attributes for the DELEG resource record itself, but that’s not important 
> for this draft.

Thanks - the domain create and info examples have been updated to include a 
custom RR type to demonstrate its use and also to ensure the test script 
catches any similar errors to the one above.

> What’s not clear in the server, is the set of  elements to return in the 
> info response.  Should the server return only the  elements that have 
> been explicitly set or should the server return the  elements for all 
> support resource record types?  Inclusion of the TTL server policy attributes 
> (“min”, “max”, and “default”)  would make the case to include all supported 
> resource record types, which seems overkill to include in all domain and host 
> info responses by default.  I believe it’s best to extend the info command 
> with an  element that includes the option to include the policy 
> attributes in the info response, which would also include the full set of 
> supported resource record types with the server policy attributes.

This makes sense. I will add this into the next version.

Thanks,

G.

>  Such as the following domain info command extensions:
> 
> Domain Info Command that only includes the set TTL records in the domain info 
> response:
> 
> 
>  
>
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>example.com
>  
>
>
>  xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"/>
>
>ABC-12345
>  
> 
> 
> Domain Info Command that includes the supported TTL records with the server 
> policy attributes in the domain info response:
> 
> 
>  
>
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>example.com
>  
>
>
>  xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" 
>policy="true"/>
>
>   ABC-12345
>  
> 
> 
> This enables the client to choose what information they want included in the 
> info response and does not include the TTL extension with all support TTL 
> records by default in every domain and host response.
> 
> Thanks,
> 
> -- 
> 
> JG 
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!9s5nhFb-JXzF0SNOLPII-gF_O1S2O0nD8gu5OqFzQs-mbMr58PVYKJK8Xy0gDAOX8Zi2VJpyM2lAea4sfMvGJIXurIgrbW10k4nuclr9$
>  [verisigninc[.]com]> 
> 
> 
> 
> 
> On 12/14/23, 12:26 PM, "regext on behalf of Gavin Brown" 
> mailto:regext-boun...@ietf.org> on behalf of 
> gavin.br...@icann.org <mailto:gavin.br...@icann.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. 
> 
> 
> Greetings all,
> 
> 
> I have just uploaded draft-ietf-regext-epp-ttl-04.
> 
> 
> Notable changes in this version:
> 
> 
> * The "for" attribute is now an enumeration, and can take the following 
> values: NS, DS, DNAME, A, , custom.
> 
> 
> * If the "for" attribute is "custom", then the "custom" attribute can be used 
> to specify a DNS record type other than those above. However, it still has to 
> match the regular expression from RFC 6895 and still has to be registered 
> with IANA.
> 
> 
> *  elements - in responses only - must have the "min", "default" and 
> "max" attributes. I'm open to feedback ab

Re: [regext] [Ext] Re: RDAP-X draft adoption

[Gavin Brown]

On 16 Nov 2023, at 15:34, Andrew Newton  wrote:

> Consider a network operator
> writing a shell script using curl and jq to find the most specific
> covering networking of an IP. Using the bootstrap files requires
> downloading the appropriate file (there are different ones for v4 and
> v6), sorting the service hosts by "http" scheme, and using an advanced
> dsa such as a trie or modified bst. Plus to be a good netizen, they
> need to deal with the cache-control of the bootstrap file. Or they can
> point curl at a redirect service and not worry about all that. That
> is, the bootstrap process is doable but it is certainly non-trivial.
> 
> For constrained environments a local bootstrap service is beneficial
> as it cuts down on the bandwidth/latency of every client grabbing the
> bootstrap files.

To add some data to Andy’s anecdote, the rdap.org service, which I run, 
currently handles around 10 million requests per day. Every request which is 
for a resource for which an RDAP URL can be constructed results in a redirect, 
so it’s clearly something that many implementers (such as those using curl + 
jq) rely on.

G.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] CALL FOR ADOPTION: draft-jasdips-regext-rdap-geofeed

[Gavin Brown]

I support adoption of this document and am willing to be the document shepherd.

G.

> On 20 Nov 2023, at 14:36, Antoin Verschuren  
> wrote:
> 
> This is a formal adoption request for An RDAP Extension for Geofeed Data:
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/__;!!PtGJab4!-QAxQKFphWOHxBEdNCnOSOvcd2N0KVhrsg_243VjMVQwRL21YfOEnD3JMkrnwXqaJfLNswubklpWrM-DfDdmaXWKpoHD6yZJ4hKtMT_a$
>  [datatracker[.]ietf[.]org]
> 
> 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 Monday 4 December.
> 
> If there are no objections, the chairs will consider this document adopted.
> 
> Thanks,
> 
> Your REGEXT co-chairs Jim and Antoin
> 
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-QAxQKFphWOHxBEdNCnOSOvcd2N0KVhrsg_243VjMVQwRL21YfOEnD3JMkrnwXqaJfLNswubklpWrM-DfDdmaXWKpoHD6yZJ4o5zn8YO$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org



smime.p7s
Description: S/MIME cryptographic signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Gavin Brown]

+1

> On 13 Nov 2023, at 15:53, James Galvin  wrote:
> 
> Following up from last week’s REGEXT meeting, there was consensus in the room 
> that the document:
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact-16/__;!!PtGJab4!5VnbfMvjkdb91qk4OBUxF1QEN2yM0_zQG6pRrvJqprNUBr3vF5kejsi7x7XuFWGVwkG1Fu7WDPKaMVJS1h23Mkg$
>  [datatracker[.]ietf[.]org]
> 
> Should be split into two documents: the signaling function and the extension.
> 
> The signaling function draft would be put on the standards track and the 
> extension draft would be put on the experimental track.
> 
> With this message the Chairs are asking the broader working group to confirm 
> this action.  If you have questions or concerns please reply to this message 
> by Monday, 20 November 2023.  If you need more time please ask on the list 
> and the Chairs will consider an extension.
> 
> Although we had consensus in the meeting room, the Chairs would appreciate a 
> “+1” reply if you agree with this action.
> 
> Thanks,
> 
> Antoin and Jim
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!5VnbfMvjkdb91qk4OBUxF1QEN2yM0_zQG6pRrvJqprNUBr3vF5kejsi7x7XuFWGVwkG1Fu7WDPKaMVJSsR6iqvI$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org



smime.p7s
Description: S/MIME cryptographic signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-08.txt

[Gavin Brown]

Hi all,

This version of the draft incorporates Rick's feedback as discussed last week.

Chairs: I would like to request Working Group Last Call for this document.

Thanks,

Gavin.

> Internet-Draft draft-ietf-regext-epp-ttl-08.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-08.txt
>   Pages:   28
>   Dates:   2024-04-16
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   https://github.com/gbxyz/epp-ttl-extension
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-08
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-08
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> 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] [Ext] I-D Action: draft-ietf-regext-epp-ttl-08.txt

[Gavin Brown]

Hi Jim and Antoin,

Please can you also submit this document to the DNS Directorate for review?

Thanks,

> On 16 Apr 2024, at 07:18, Gavin Brown  wrote:
> 
> Hi all,
> 
> This version of the draft incorporates Rick's feedback as discussed last week.
> 
> Chairs: I would like to request Working Group Last Call for this document.
> 
> Thanks,
> 
> Gavin.
> 
>> Internet-Draft draft-ietf-regext-epp-ttl-08.txt is now available. It is a 
>> work
>> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
>> 
>>  Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
>> Time-To-Live (TTL) values
>>  Author:  Gavin Brown
>>  Name:draft-ietf-regext-epp-ttl-08.txt
>>  Pages:   28
>>  Dates:   2024-04-16
>> 
>> Abstract:
>> 
>>  This document describes an extension to the Extensible Provisioning
>>  Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>>  (TTL) value for domain name delegation records.
>> 
>> About this draft
>> 
>>  This note is to be removed before publishing as an RFC.
>> 
>>  The source for this draft, and an issue tracker, may can be found at
>>  https://github.com/gbxyz/epp-ttl-extension
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
>> 
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-08
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-08
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> regext mailing list
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] Re-chartering REGEXT?

[Gavin Brown]

Hi Maarten,

I have some comments about your points, which I will insert below.

> On 25 Apr 2024, at 08:15, Maarten Wullink 
>  wrote:
> 
> Jim, Scott,
> 
> There exists a lot of confusion about REPP, here is my attempt to try to 
> answer some of these question.
> 
> Q) What is the goal of REPP?
> 
> A) The goal is to create a "RESTful API for EPP" to increase scalability of 
> an EPP service, make it easier to integrate into registry/registrar systems
> through the use of modern HTTP/REST based APIs and also include support for 
> other data formats such as JSON. 
> Maybe, a good analogy would be that REPP would be to EPP, what RDAP is to 
> WHOIS?

If "scalability" (based on a cloud paradigm which is designed around HTTP) is 
the sole objective, then I think that draft-loffredo-regext-epp-over-http would 
be the "smallest shippable delta" to achieve that objective.

However, your use of the term "REST", and the effective forking of EPP's XML 
syntax for commands and responses (in order to make substantial changes to 
them), do not seem to relate to this objective.

I would encourage you to be explicit in the objectives you're seeking to 
achieve with this proposal, since "scalability" is insufficient to justify most 
of what's proposed in your draft.

> Q) Is REPP a stateless version of EPP?
> 
> A) No, REPP can be designed to be stateful to conform to the requirement 
> (RFC5730 section 2.1) that a transport MUST preserve the stateful nature of 
> the EPP protocol.
> When using REPP, EPP is layered over HTTTP and REST, which are both 
> stateless, but the EPP protocol itself can be kept stateful.

REST is not something that can be "layered" over, it is an architectural 
approach based on hypermedia concepts.

I would argue that REPP is only partially "RESTful" (as it was defined by Roy 
Fielding), in that it lacks the hypermedia controls (HATEOAS, Hypermedia As The 
Engine of Application State) of a true REST design. At most, it meets the 
criteria for Level 2 of the Richardson Maturity Model (to be clear, 
draft-loffredo-regext-epp-over-http isn't REST either, but RESTfulness is not 
one of its design goals).

If REPP is not REST, and also not EPP, then it is poorly named, and I think you 
would cause less confusion and win more support with a different name. It's a 
small thing but could have a big impact.

> This is similar to the draft proposal for EPP over HTTP and Quic. After the 
> login request, the client would receive a session identifier/token to couple 
> the server state to the client.
> 
> Q) Do we need to change the existing EPP RFCs?
> 
> A) No, for REPP we would not need to change any of the existing EPP RFCs.

Only because you plan to fork the formal specifications, resulting in two 
incompatible grammars for the same fundamental concepts. This means that it may 
not be possible for an extension designed for EPP to be used with REPP (and 
vice versa) moving forward, which would harm both protocols.

> Q) Are the existing EPP extensions compatible with REPP?
> 
> A) Yes, all existing EPP extensions should work fine, we have have not worked 
> out all the details
> but we do feel that this is not an issue.

I think this is a matter that you should address urgently since EPP's 
extensibility is fundamental to its success as a protocol, and implementers (of 
both clients and servers) will be extremely reluctant to jettison two decades' 
of work and start again from the ground up.

Regards,

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gavin Brown]

Hi Scott,

Thanks for that - I will update the wording.

G.

> On 30 Apr 2024, at 14:17, Hollenbeck, Scott 
>  wrote:
> 
> I've reviewed the draft again. I think it's ready modulo one minor nit:
> 
> Section 1.1: The text currently says "in this document are to be interpreted 
> as described in [RFC2119]". Current convention is to say "in this document 
> are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and 
> only when, they appear in all capitals, as shown here".
> 
> Scott
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!4P3dFZLoTlnATMxQfwQUEqHl3nEMTgvzLTQrWoPldTKjY-XFAeDDpN2wFELc4nJFJ8XDVaIClNKmEatwKXUyTJzSLhdxS2QItqr7lBp_$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gavin Brown]

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, 13 May 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 <mailto:regext@ietf.org>
> > https://secure-web.cisco.com/1BCU29KkyrRwXsVnp2SCDnWq8JA-lZcDf-1PUkJB0ixWpHA1iSWHnLCFKwW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> >  
> > <https://secure-web.cisco.com/1BCU29KkyrRwXsVnp2SCDnWq8JA-lZcDf-1PUkJB0ixWpHA1iSWHnLCFKwW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>   -- Dott. Mario Loffredo
> Senior Technologist
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: 
> http://secure-web.cisco.com/134XlqUuJFfEY9v3lKkJSznN8BO2tUE7I_cmE7I6eB0gImy2AMsXx8rbgbfAHhGjp-ltYXNCnoHplH9sYUVPkV-Ff6Sus0CMB2_7O3e3xGxnfPkPd_YsfbsqRyJMqAidHzRizWbu-funY_QesIUYYXg_3bL5X3zCi4SDq0JpBUFbZxd2a796Ekya7Fbul8UWM7MGU-Q2K4-Q85grC5WltnvdBiNOd5mjtSwlw3LpNBirtdXS6yTNYqE_ajbKjREjcZhj7BJrrOoSqU0j6BQ162RSL0bS9AeokpOcNyAl6SxE/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
>  
> <http://secure-web.cisco.com/134XlqUuJFfEY9v3lKkJSznN8BO2tUE7I_cmE7I6eB0gImy2AMsXx8rbgbfAHhGjp-ltYXNCnoHplH9sYUVPkV-Ff6Sus0CMB2_7O3e3xGxnfPkPd_YsfbsqRyJMqAidHzRizWbu-funY_QesIUYYXg_3bL5X3zCi4SDq0JpBUFbZxd2a796Ekya7Fbul8UWM7MGU-Q2K4-Q85grC5WltnvdBiNOd5mjtSwlw3LpNBirtdXS6yTNYqE_ajbKjREjcZhj7BJrrOoSqU0j6BQ162RSL0bS9AeokpOcNyAl6SxE/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>   ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://secure-web.cisco.com/1BCU29KkyrRwXsVnp2SCDnWq8JA-lZcDf-1PUkJB0ixWpHA1iSWHnLCFKwW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>  
> <https://secure-web.cisco.com/1BCU29KkyrRwXsVnp2SCDnWq8JA-lZcDf-1PUkJB0ixWpHA1iSWHnLCFKwW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>   ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext


--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-02.txt

[Gavin Brown]

Hi Scott,

My apologies that this feedback comes after you've requested WGLC! I had been 
meaning to review the document properly and got caught out. I have a couple of 
minor points and one somewhat less minor.

Full disclosure to the WG: I was an occasional participant in the SSAC group 
from which Scott's efforts arose. I did contribute something to the report but 
the last I checked my minor contributions had been removed, so I have no skin 
in this game :)

Section 3.1: the last paragraph describes how allowing host objects to exist 
after deletion of their superordinate domain object invites hijacking. This is 
correct, but it would also constitute orphan glue, which I think is worth 
mentioning, perhaps with a reference to SSAC 048.

Section 3.2 discusses how servers that implicitly delete subordinate host 
objects in response to requests to delete a domain objects can create a data 
inconsistency condition. This is true, but in my experience from my time at 
$DAYJOB[-1], where we did this, we never received any complaints from 
registrars in all the time those complaints would have reached my desk (which 
was a long time). I think the current text should stand, but I would suggest 
adding that the potential impact of this inconsistency appears to be small.

Onto my less minor point.

Section 6.1 describes what the document considers to be the Best Current 
Practice. However, Section 6.2 then lists two "Best Proposed Practices", with 
no context on how those relate to the practice in the preceding section.

Are they "runners up"? Are they proposeed "Best Practices"? If a registry 
implements the practices in 6.2.1 or 6.2.2, do they then not need to implement 
6.2?

I would recommend adding some context here. If 6.2.1 and 6.2.2 are Best 
Practices, they belong in 6.1. If they aren't, then their relationship to 
what's in 6.1 needs some clarification.

Otherwise I think this document does a good job of explaining the issues and 
outlining the solution(s) (best, slightly less best, or otherwise).

Cheers,

G.

> On 9 May 2024, at 15:56, Hollenbeck, Scott 
>  wrote:
> 
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Tuesday, May 7, 2024 10:51 AM
>> To: i-d-annou...@ietf.org
>> Cc: regext@ietf.org
>> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-epp-delete-bcp-02.txt
>> 
>> 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.
>> 
>> Internet-Draft draft-ietf-regext-epp-delete-bcp-02.txt is now available. It 
>> is a
>> work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
>> 
>>   Title:   Best Practices for Deletion of Domain and Host Objects in the
>> Extensible Provisioning Protocol (EPP)
>>   Authors: Scott Hollenbeck
>>William Carroll
>>Gautam Akiwate
>>   Name:draft-ietf-regext-epp-delete-bcp-02.txt
>>   Pages:   20
>>   Dates:   2024-05-07
>> 
>> Abstract:
>> 
>>   The Extensible Provisioning Protocol (EPP) includes commands for
>>   clients to delete domain and host objects, both of which are used to
>>   publish information in the Domain Name System (DNS).  EPP also
>>   includes guidance for deletions that is intended to avoid DNS
>>   resolution disruptions and maintain data consistency.  However,
>>   operational relationships between objects can make that guidance
>>   difficult to implement.  Some EPP clients have developed operational
>>   practices to delete those objects that have unintended impacts on DNS
>>   resolution and security.  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.
> 
> [SAH] With this update the editors believe this draft is ready for working 
> group last call. Please say otherwise if you disagree.
> 
> Scott
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

Re: [regext] [Ext] Re-chartering REGEXT?

[Gavin Brown]

Hi Maarten,

> On 25 Apr 2024, at 13:10, Maarten Wullink 
>  wrote:
>> 
>> I would encourage you to be explicit in the objectives you're seeking to 
>> achieve with this proposal, since "scalability" is insufficient to justify 
>> most of what's proposed in your draft.
> 
> Improved scalability is one the stated goals and It’s true that just by 
> adding HTTP support, EPP would be able to leverage all of the scalability 
> features provided by HTTP.
> 
> However, by using named resources in the URL (as is a feature of REST) it 
> would also be possible to include more advanced forms of load balancing, such 
> as routing requests based on the request URL pattern. An example would be a 
> configuration where informational requests such the CHECK and INFO are 
> separated from the creational requests such as CREATE and UPDATE. 

[snip]

> We added a new XML schema in our last version to better align the EPP XML to 
> the RESTful style, if this is a blocking issue, then we can remove the new 
> XML schema in the next version and go back to using the XML schema from RFC 
> 5730.

Thanks for providing this context, it's helpful to understand what the 
objectives are.

As I understand it, the rationale is to move some protocol elements from the 
XML to elsewhere in the HTTP message so that these can be used to control 
routing, caching, load balancing, etc.

*Copying* these elements would achieve the same effect, and altering the XML 
schema just to avoid duplication throws the baby out of the bathwater. I would 
strongly recommend that the schemas from RFCs 5730-5733 remain unchanged.

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Re: [Ext] I-D Action: draft-ietf-regext-epp-ttl-09.txt

[Gavin Brown]

Thanks to all who gave their +1 during the WGLC. This version incorporates all 
the feedback received during this period.

G.

> On 13 May 2024, at 15:46, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-09.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-09.txt
>   Pages:   28
>   Dates:   2024-05-13
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   
> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!9rzeemUpsU8WpOr-vOQdr2kJO_Jla9HDDLkUunSr0pPHLpq8-hUpsqZqcGpRcuYu7m3lf9pdQw4vRNgcAREzWUoLd_0qNxtsuw$
>  [github[.]com].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!9rzeemUpsU8WpOr-vOQdr2kJO_Jla9HDDLkUunSr0pPHLpq8-hUpsqZqcGpRcuYu7m3lf9pdQw4vRNgcAREzWUoLd_36eE4fkQ$
>  [datatracker[.]ietf[.]org]
> 
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-09__;!!PtGJab4!9rzeemUpsU8WpOr-vOQdr2kJO_Jla9HDDLkUunSr0pPHLpq8-hUpsqZqcGpRcuYu7m3lf9pdQw4vRNgcAREzWUoLd_1sMOhBYQ$
>  [datatracker[.]ietf[.]org]
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-09__;!!PtGJab4!9rzeemUpsU8WpOr-vOQdr2kJO_Jla9HDDLkUunSr0pPHLpq8-hUpsqZqcGpRcuYu7m3lf9pdQw4vRNgcAREzWUoLd_2iqM4s-w$
>  [author-tools[.]ietf[.]org]
> 
> 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

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-02.txt

[Gavin Brown]

Hi Scott,

> On 9 May 2024, at 20:33, Hollenbeck, Scott  wrote:

[snip]

>> Section 6.1 describes what the document considers to be the Best Current
>> Practice. However, Section 6.2 then lists two "Best Proposed Practices", with
>> no context on how those relate to the practice in the preceding section.
>> 
>> Are they "runners up"? Are they proposeed "Best Practices"? If a registry
>> implements the practices in 6.2.1 or 6.2.2, do they then not need to
>> implement 6.2?
>> 
>> I would recommend adding some context here. If 6.2.1 and 6.2.2 are Best
>> Practices, they belong in 6.1. If they aren't, then their relationship to 
>> what's in
>> 6.1 needs some clarification.
> 
> [SAH] The context is given in the Section title and the included back 
> references. They're proposed best practices. The back-referenced text that 
> describes each practice notes that they haven't been observed in operation. 
> We could add something like "The practices in this section are described as 
> "best practices" because they address the operational risk and have been 
> observed in operation" to 6.1 and "The practices in this section are 
> described as "proposed best practices" because they address the operational 
> risk and haven't been observed in operation" to 6.2. Would that help?

Yes, I think it would.

Thanks.

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Dnsdir early review of draft-ietf-regext-epp-ttl-09

[Gavin Brown]

Thanks for your review, Anthony. I will make the suggested changes.

G.

> On 16 May 2024, at 07:29, Anthony Somerset via Datatracker  
> wrote:
> 
> Reviewer: Anthony Somerset
> Review result: Ready with Nits
> 
> Hi,
> 
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the ADs.
> For more information about the DNS Directorate, please see
> https://urldefense.com/v3/__https://wiki.ietf.org/en/group/dnsdir__;!!PtGJab4!55awyF4-Xlych34VHVJOir2Nxa7yd1CVRT6LR7eIsrLJ2_IKW7kd28j3KJwpWA0xGsun332v1zx2JtEKNF90KD0$
>  [wiki[.]ietf[.]org]
> 
> This document is well written and clear enough even with all the XML 
> references :) I believe all DNS related standards are respected here and this 
> would be a valuable extension to EPP. I believe this document is Ready but 
> with 1 important NIT and one clarification
> 
> NIT
> 
> While the IPv4 addresses referenced in the examples uses the documentation 
> prefix as per RFC5737 i note that IPv6 addresses are not following the same 
> principle as per RFC3849 - I recommend that IPv6 addresses in the document be 
> updated accordingly, from what i can see a simple find and replace on 
> "1080::" 
> with "2001:DB8::" should do the trick.
> 
> CLARIFICATION
> 
> I do have one clarifying query though with regards to section 3.1 on 
> Permitted 
> record types. How does a server signal to a client which record types are 
> permitted beyond returning an error to an update command. After reading the 
>  section again more carefully it says that supported 
> record types would be returned by the server - perhaps one could be more 
> explicit in section 3.1 to make reference to the ttl:info portion of the info 
> response?
> 
> Thanks for your hard work on this draft
> 
> Best Regards
> 
> Anthony
> 

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] I-D Action: draft-ietf-regext-epp-ttl-10.txt

[Gavin Brown]

Hi all,

This version addresses Anthony's suggestions.

G.

> On 16 May 2024, at 14:08, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-10.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-10.txt
>   Pages:   29
>   Dates:   2024-05-16
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   
> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!7X7n-RHaOr_uka4kick0QCIAXaMxCtjPYFPOV7iFLvZ0ZlJYT297ukn_B-Hf2sd1MLXGg-LzDx2SySIuzKMY9VbS-fWmIAfU0g$
>  [github[.]com].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!7X7n-RHaOr_uka4kick0QCIAXaMxCtjPYFPOV7iFLvZ0ZlJYT297ukn_B-Hf2sd1MLXGg-LzDx2SySIuzKMY9VbS-fXu5eR-zA$
>  [datatracker[.]ietf[.]org]
> 
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-10__;!!PtGJab4!7X7n-RHaOr_uka4kick0QCIAXaMxCtjPYFPOV7iFLvZ0ZlJYT297ukn_B-Hf2sd1MLXGg-LzDx2SySIuzKMY9VbS-fViHwm0Pg$
>  [datatracker[.]ietf[.]org]
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-10__;!!PtGJab4!7X7n-RHaOr_uka4kick0QCIAXaMxCtjPYFPOV7iFLvZ0ZlJYT297ukn_B-Hf2sd1MLXGg-LzDx2SySIuzKMY9VbS-fXXGJdxog$
>  [author-tools[.]ietf[.]org]
> 
> 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

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

Re: [regext] [Ext] [EXTERNAL] I-D Action: draft-ietf-regext-epp-ttl-07.txt

[Gavin Brown]

Hi Rick, thanks for sharing your feedback, my responses are below.

> On 8 Apr 2024, at 15:52, Rick Wilhelm  
> wrote:
> 
> Gavin, et al,
>  This is a mixture of nits and wording things.  I had provided this privately 
> to Gavin, he indicated it was better to just send directly to the list.
>   1.2.1:
> The  element may have the following attributes, depending on
>  Q1:  The use of the uncapitalized ‘may’ here could be confusing.  Can that 
> be capitalized?  Or perhaps reworded?

I will capitalize "MAY" here as suggested.

>  3.  "min", which MUST NOT be present in commands frames but MAY be
> and
>4.  "default", which MUST NOT be present in commands frames but MAY
> and
>5.  "max", which MUST NOT be present in commands frames but MAY be
>  Q2:  In all three of these, I think that “commands” should singular; as in 
> “… in command frames” (or perhaps “…in a command frame” ??)

Agreed, corrected.

>   1.2.1.2
> [RFC6895], and is intended to match any existing and future RRTYPE
>  I think that we mean “existing or future” ?

I've reworded this slightly to say:

"The regular expression [...]  is intended to match both existing and future 
RRTYPE mnemonics."

I think this wording is clearer.

>   this document in the event that a new DNS record that exists above a
>zone cut is specified.
>  I think that eliding the part about “exists above a zone cut” would be 
> helpful, because someone will argue about “what is a zone cut?  And why 
> haven’t you defined it??”So perhaps:   “… in the event that a new DNS 
> record (type?) is specified.”
>   1.2.1.2.1

I've reworded this to say (continuing from the sentence above):

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

This adds an informational reference to RFC9499 so it's clear what is meant by 
a zone cut.

>  These
>servers MUST reject commands which attempt to set TTL values for
>these record types for domain objects using a 2004 "Parameter value
>range" error.
>  Noting that just above this text, in 1.2.1.2, the doct uses a different form 
> for a 2004 error code.  For consistency, would suggest text of:
>  A server which implements host objects and receives a command which attempts 
> to set TTL values for these record types on a domain objects MUST respond 
> with a 2004 “Parameter value range” error.

I've updated the wording to be consistent in both places.

>3.1
>  Servers MAY restrict the supported DNS record types in accordance
>with their own operational needs.
>  Suggest that “needs” be replaced with the more clear and direct “policy”

Agreed.

>   3.2
> EPP servers which implement this extension SHOULD use the values
>provided by EPP clients for the TTL values records published in the
>DNS for domain and and objects.
>  Seems like this sentence should give a nod to server policy.  For example, 
> just above this text, there is text that states:
> If an EPP server receives an  command containing a TTL value
>that is outside the server's permitted range, it MUST reject the
>command with a 2306 "Parameter value policy error" response.
>  Perhaps the sentence in 3.2 could read:
> EPP servers which implement this extension SHOULD use the values
>provided by EPP clients for the TTL values records published in the
>DNS for domain and and objects, if such values conform to server policy.

I think this change is redundant, since the server already MUST reject any 
transform command that tries to set a TTL value outside the permitted policy; 
therefore there is no need for additional server logic to check if supplied TTL 
values conform to server policy when publishing records in the DNS, since those 
values will already conform to that policy. Does that make sense?

>5.1:   (this will be an odd comment, coming from me!!
>Domain registry operators must strike a balance between, on the one
>hand, the desire of registrants for changes to their domains to be
>visible in the DNS quickly, and on the other, the increased DNS query
>traffic that short TTLs can bring.
>  While I firmly believe that the statement as written, I’m not sure if this 
> belongs in the RFC.  In the spirit of “suggest text”:  I think that perhaps 
> the statement that goes in the RFC is that:  “Domain registry operators must 
> consider the balance between, on the one hand, …” (and continue from there).  
>   That is, I think that the notion of “striking a balance” is a value 
> judgement, but to “consider the balance” is judgement-free.  Hmm!!

Agreed, I've u

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-07.txt

[Gavin Brown]

Hi all,

As discussed during the meeting in Brisbane last week, this version addresses 
all feedback received since -06 was published.

I consider this document ready for WGLC.

G.

> On 26 Mar 2024, at 11:11, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-07.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-07.txt
>   Pages:   28
>   Dates:   2024-03-26
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   
> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcj8YpYKA$
>  [github[.]com].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcK0W3swA$
>  [datatracker[.]ietf[.]org]
> 
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFenfewX_w$
>  [datatracker[.]ietf[.]org]
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFdXESIG3A$
>  [author-tools[.]ietf[.]org]
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFfzsmm-bg$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-06.txt

[Gavin Brown]

Hi all,

This new version reflects feedback received including Jim's regarding the 
server behaviour when processing  commands.

Two "modes" are defined: the default mode and the "policy" mode:

* default mode ( absent or with policy=false): include  elements 
for non-default values only, no min/default/max

* policy mode ( present with policy=true): include  elements for 
all supported record types with min/default/max attributes.

Please review!

G.

> On 1 Mar 2024, at 12:23, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-regext-epp-ttl-06.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-06.txt
>   Pages:   29
>   Dates:   2024-03-01
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   
> https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!6oxU9A5-atpTHqbcKZW8zvG5Z51EtyHQl1C8sE6Daaz4T4_PWZeCfXoLiAL6X_Ro4QkyR-NC2qnYK8spQGhPW-KVAnFZMHl3eg$
>  [github[.]com].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!6oxU9A5-atpTHqbcKZW8zvG5Z51EtyHQl1C8sE6Daaz4T4_PWZeCfXoLiAL6X_Ro4QkyR-NC2qnYK8spQGhPW-KVAnG3a-VFYg$
>  [datatracker[.]ietf[.]org]
> 
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-06__;!!PtGJab4!6oxU9A5-atpTHqbcKZW8zvG5Z51EtyHQl1C8sE6Daaz4T4_PWZeCfXoLiAL6X_Ro4QkyR-NC2qnYK8spQGhPW-KVAnG_sMjJ6A$
>  [datatracker[.]ietf[.]org]
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-06__;!!PtGJab4!6oxU9A5-atpTHqbcKZW8zvG5Z51EtyHQl1C8sE6Daaz4T4_PWZeCfXoLiAL6X_Ro4QkyR-NC2qnYK8spQGhPW-KVAnGSN0VWmQ$
>  [author-tools[.]ietf[.]org]
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!6oxU9A5-atpTHqbcKZW8zvG5Z51EtyHQl1C8sE6Daaz4T4_PWZeCfXoLiAL6X_Ro4QkyR-NC2qnYK8spQGhPW-KVAnGYxjBlwg$
>  [ietf[.]org]

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt

[Gavin Brown]

Hi Jim, thanks for this - I've reviewed and agree, and will publish a -06 
version some time soon which reflects this approach.

Cheers,

Gavin.

> On 7 Feb 2024, at 21:17, Gould, James  wrote:
> 
> Gavin, 
> 
> My feedback is included below.
> 
> -- 
> 
> JG 
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!5TKqQZgF-fFtaBWMyjr4L_bFUTdhCYDuZ7I__5YfR0HrgHAu3Tue2WFr-2APuvO-K2D7ZFgCCrlAR_fhQARHLdz5$
>  [verisigninc[.]com]> 
> 
> 
> 
> 
> On 2/7/24, 12:43 PM, "Gavin Brown"  <mailto:gavin.br...@icann.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. 
> 
> 
> Hi Jim,
> 
> 
> Thanks for this feedback.
> 
> 
> Am I correct in saying that in your view, if a server receives an unextended 
>  command (on a session where the TTL extension was included in an 
>  element in the  frame) then the  response should not 
> include the  element in the response?
> 
> JG - Correct, the inclusion of the ttl extension in the info command would 
> trigger inclusion of the ttl extension in the info response.
> 
> 
> If that's the case, then this seems somewhat at variance with the approach 
> taken historically: for example, one does not need to extend the  
> command to get the  and  elements in the  
> response.
> 
> JG - The difference here is that the secDNS and rgp extensions are included 
> in the response if they have dnssec and rgp data, which will be a subset of 
> the domain names.  The original form of the ttl extension included the policy 
> information that includes ttl information for all support resource records 
> for all responses, which can increase the size of all info responses.   I 
> could see including the ttl extension based on the login services only when 
> the ttl was explicitly set, which would be a subset of the domain names and 
> it would limit the amount of information included in the response.  Inclusion 
> of the policy information needs to be explicitly included in the extension to 
> the info command.  
> 
> Are there examples of more recent extensions which require an extension to an 
>  command to get an extended  response? I would not consider the 
> launch extensions here for example, since it requires the client to provide 
> parameters in order to satisfy the request.
> 
> JG - Examples include:
> 
> 1. The launch extension in RFC 8334, as you noted
> 2. allocation token extension in RFC 8495
> 3. whois info extension 
> (https://urldefense.com/v3/__https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_whois-info_v01.html__;!!PtGJab4!5TKqQZgF-fFtaBWMyjr4L_bFUTdhCYDuZ7I__5YfR0HrgHAu3Tue2WFr-2APuvO-K2D7ZFgCCrlAR_fhQMH-7XDI$
>  [verisign[.]com]) 
> 4. related domain extension 
> (https://urldefense.com/v3/__https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v01.html__;!!PtGJab4!5TKqQZgF-fFtaBWMyjr4L_bFUTdhCYDuZ7I__5YfR0HrgHAu3Tue2WFr-2APuvO-K2D7ZFgCCrlAR_fhQBXwONJh$[verisign[.]com])
>  
> 
> There are three options that I've seen for including the extension in the 
> info response:
> 
> 1. based on the login services
> 2. based on the login services and the existence of data
> 3. based on the extension with options included in the info command
> 
> If ttl includes the extension in the response when the ttl has explicitly 
> been set and ttl in in the login services, and provides the option to get the 
> policy information via an extension to the info command, then it would use a 
> mix of option 2 and option 3.  
> 
> Thanks,
> 
> 
> Gavin.
> 
> 
> 
> 
>> On 31 Jan 2024, at 15:29, Gould, James > <mailto:jgo...@verisign.com>> wrote:
>> 
>> Gavin,
>> 
>> Thanks for making the updates to draft-ietf-regext-epp-ttl-05. I did find 
>> one issue with the XML schema, where > required="true"/> needs to be > use="required"/>. I would prefer making the "policy" attribute optional with 
>> a default value of "false", as in:
>> 
>> 
>> 
>> I would then change the description in section 1.3 to be:
>> 
>> It has a single OPTIONAL "policy" attribute, which takes a boolean value 
>> with a default value of "false". 
>> 
>> If a server receives an  command for a domain or host object which 
>> includes a  element with a "policy" attribute that is "1&

Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-06.txt

[Gavin Brown]

Hi Jim,

Thanks for the feedback, I've incorporated your suggestions into my working 
draft and they will appear in the next version.

G.

> On 1 Mar 2024, at 19:16, Gould, James  
> wrote:
> 
> Gavin,
>  Thank for posting -06.  I have reviewed the draft and updated the 
> implementation of it.  Below is my feedback:
>  
> • Nit - The last example in section 2.1.1.1 is mislabeled and should be 
> “Example host  response…”.  Also, do you want the TTL value for the “A” 
> record to match that of the Policy Mode example with a value of “172800” 
> instead of “3600”?
> • Nit – In section 1.3, change “used to by clients” to “used by clients”
> • Nit – In section 1.3, change “It has a single OPTIONAL attribute, 
> policy, which takes a boolean value with a default value of false” to “It has 
> a single OPTIONAL “policy” attribute, which is a boolean value with a default 
> value of “false”.”
> • Section 2.1.1
> • Recommend using the upper case for the modes, as in Default Mode 
> and Policy Mode and then introduce the modes via their upper-case form, as in:
>i.  The 
> EPP  command is extended to support two different modes: the Default 
> Mode (Section 2.1.1.1) and the Policy Mode (section 2.1.1.2).  The Default 
> Mode requests the inclusion of all non-default TTL values in the response. 
> The Policy Mode requests the inclusion of TTL information for all supported 
> DNS record types in the response, with the minimum value, default value, and 
> maximum value. 
> • Section 2.1.1.1
> • Use the upper-case “Default Mode” for the title
> • Update the first paragraph to reduce the number of which’s, as in:
>i.  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”, the 
> EPP  MUST contain an   element containing 
>  records for all that DNS record types that have non-default TTL 
> values.  The  elements MUST NOT have the “min”, “default”, and “max” 
> elements.
>  ii.  NOTE – 
> I’m unclear why the exclusion of the “min”, “default” and “max” elements is a 
> SHOULD NOT instead of a MUST NOT.  I believe it’s best to make it clear that 
> the Default Mode must not include the policy elements.  I don’t believe there 
> is the need to define the exclusion of the “policy” attribute, since the 
> default value of “false” will cover the absence use case.
> • Section 2.1.1.2
> • Use the upper-case “Policy Mode” for the title
> • Update the first paragraph to reduce the number of which’s, as in:
>i.  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”, the 
> EPP  MUST contain an   element containing 
>  records for all supported DNS record types, irrespective of whether 
> those record types are in use by the object.  The  elements MUST 
> have the “min”, “default”, and “max” elements.
> • Section 2.1.1.3 
> • I believe this section can be removed, since the extension covers 
> when it must be included and doesn’t need to cover when it must not be 
> included.
>  Thanks,
>  --  JGJames Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>  703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>  Verisign.com <http://verisigninc.com/> On 3/1/24, 7:52 AM, "regext on 
> behalf of Gavin Brown"  <mailto:regext-boun...@ietf.org> on behalf of gavin.br...@icann.org 
> <mailto:gavin.br...@icann.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.
>   Hi all,
>   This new version reflects feedback received including Jim's regarding the 
> server behaviour when processing  commands.
>   Two "modes" are defined: the default mode and the "policy" mode:
>   * default mode ( absent or with policy=false): include  
> elements for non-default values only, no min/default/max
>   * policy mode ( present with policy=true): include  elements 
> for all supported record types with min/default/max attributes.
>   Please review!
>   G.
>   > On 1 Mar 2024, at 12:23, internet-dra...@ietf.org 
> <mailto:internet-dra...@ietf.org> wrote:
> > > Internet-Draft draft-ietf-regext-epp-ttl-06.txt is now available. It is a 
> > > work
> > item of the Registration Protocols

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

[Gavin Brown]

wW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>  [secure-web.cisco.com] 
> <https://secure-web.cisco.com/1BCU29KkyrRwXsVnp2SCDnWq8JA-lZcDf-1PUkJB0ixWpHA1iSWHnLCFKwW51BeUqekjUmq-mP9IpgZgNMZsHMOCV__s352UM6oCzAmrVhzMkVxk5E_p-DN5euABUCFpJjnu-orG1au2TUONfaFotfFc-A_l_FZieXpz9PqUyNT2-oBRdb0vkwy9FjRHl-oi9SCuuuSdbhuFwEQRnrxwWBNUu1Hw5S4ksV4KFOp3QcJmX9FwXYkaEsXC30Oq0QqAZnXlFV5EjTV0aqJsUdkB5KyipEp8sQrvQxpe1HnUk2Fo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>  [secure-web.cisco.com]>
>   ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org


--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Fwd: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

[Gavin Brown]

Hi all,

With my RDAP client implementer hat on, I've been ruminating about how the 
users of my client(s)[1] use them, and some anecdata suggests that in general, 
consumers of registration data - in the domain space at least - are often 
equally if not more interested in the RDAP record of the sponsoring registrar 
than of the registry.

Currently, the only way for me to satisfy this user need is to get the RDAP 
record from the registry, parse it to find the "related" link, and then requery 
for that.

This draft outlines a possible approach to improving the performance of this 
use case, by putting relevant links into the header of the response. The client 
can then use the HEAD method, saving bandwidth and compute resources on both 
sides, and offering a better experience for the user.

Feedback is welcome!

G.

> Begin forwarded message:
> 
> From: 
> Subject: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt
> Date: 23 May 2024 at 20:42:19 BST
> To: Andy Newton , Gavin Brown 
> 
> A new version of Internet-Draft draft-brown-rdap-referrals-00.txt has been
> successfully submitted by Gavin Brown and posted to the
> IETF repository.
> 
> Name: draft-brown-rdap-referrals
> Revision: 00
> Title:Efficient RDAP Referrals
> Date: 2024-05-23
> Group:Individual Submission
> Pages:6
> URL:  https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-brown-rdap-referrals/
> HTML: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-brown-rdap-referrals
> 
> 
> Abstract:
> 
>   This document describes how RDAP servers can provide HTTP "Link"
>   header fields in RDAP responses to allow RDAP clients to efficiently
>   determine the URL of related RDAP records for a resource.
> 
> 
> 
> The IETF Secretariat
> 
> 
> --
> Gavin Brown
> Principal Engineer, Global Domains & Strategy
> Internet Corporation for Assigned Names and Numbers (ICANN)
> 
> https://www.icann.org

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

[regext] Re: [Ext] Re: regext - New Meeting Session Request for IETF 120

[Gavin Brown]

+1

> On 3 Jun 2024, at 15:52, Andrew Newton (andy)  wrote:
> 
> Given the interims that never materialized, the discussions on EPP over 
> REST/HTPP/QUIC, the drafts on IDNS that are expected, and the recent issues 
> on RDAP redaction, would it be wise to also ask for an additional 1 hour slot?
> 
> -andy
> 
> On 6/3/24 10:40, IETF Meeting Session Request Tool wrote:
>> 
>> A new meeting session request has just been submitted by Antoin Verschuren, a
>> Chair of the REGEXT Working Group.
>> 
>> 
>> -
>> Working Group Name: Registration Protocols Extensions
>> Area Name: Applications and Real-Time Area
>> Session Requester: Antoin Verschuren
>> 
>> 
>> Number of Sessions: 1
>> Length of Session(s): 2 Hours
>> Number of Attendees: 50
>> Conflicts to Avoid:
>>  Chair conflict: dnsop dance saag sidrops savnet grow deleg
>>  Key participant conflict: dispatch secdispatch
>> 
>>
>> 
>> Participants who must be present:
>> 
>> Resources Requested:
>> 
>> Special Requests:
>>   -
>> 
>> 
>> ___
>> 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

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] I-D Action: draft-ietf-regext-epp-ttl-11.txt

[Gavin Brown]

This version fixes the "double and" issue previously reported by Jody.

G.

> Internet-Draft draft-ietf-regext-epp-ttl-11.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>   Title:   Extensible Provisioning Protocol (EPP) mapping for DNS 
> Time-To-Live (TTL) values
>   Author:  Gavin Brown
>   Name:draft-ietf-regext-epp-ttl-11.txt
>   Pages:   29
>   Dates:   2024-06-03
> 
> Abstract:
> 
>   This document describes an extension to the Extensible Provisioning
>   Protocol (EPP) that allows EPP clients to manage the Time-To-Live
>   (TTL) value for domain name delegation records.
> 
> About this draft
> 
>   This note is to be removed before publishing as an RFC.
> 
>   The source for this draft, and an issue tracker, may can be found at
>   https://github.com/gbxyz/epp-ttl-extension
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-11
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-11
> 
> 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

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

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

[Gavin Brown]

I support publication of this document.

> On 3 Jun 2024, at 15: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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/__;!!PtGJab4!_HYJtMnaJVIqKxRXO6ZgLxJOFaTgMTAQqVSy1cSPZbLj2BZ9Zmj-8d4CQq_tKdZGlPE4fX2m9WK70whIKYrjxJ0$
>  [datatracker[.]ietf[.]org]
> 
> 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

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Gavin Brown]

> On 5 Jun 2024, at 16:54, Gould, James  
> wrote:
> 
> Andy,
>  As noted in my prior response, below is my detailed responses to 
> draft-newton-regext-rdap-considerations-on-rfc9537:
>  
> • Abstract
> • “Some of these problems may be insurmountable, leaving portions of 
> RFC 9537 non-interoperable between clients and servers, while other problems 
> place a high degree of complexity upon clients.”
> i. The RFC provides a set of required members for each redaction 
> with the “name” and “method” members, along with a set of optional members.  
> Your considerations focus on the implementation of the optional members that 
> use an expression language (JSONPath) to technically identify the JSON 
> members redacted via the supported methods.  We’ve had a lot of discussion on 
> the list with the inherent complexity of RDAP and jCard containing structured 
> and unstructured content that any JSON expression language will have 
> challenges with.  I still believe that JSONPath is the appropriate expression 
> language to use currently, but the RFC supports extensibility of expression 
> languages if a better expression language is created.  At a minimum, the 
> client should be capable of easily leveraging the required “name” and 
> “method” members to provide a list of redactions to the end users with 
> optional visual field-level indication, which is not insurmountable and can 
> be done in an interoperable way.  

With my client developer hat on, I disagree with this last statement. If I had 
an existing tool that was used to presenting Whois records that I was 
retrofitting to support RDAP, then perhaps it would be the case, but the "name" 
property of a redaction object is useless unless I completely rewrite my 
clients so that they use a Whois-style internal data model, which is much less 
flexible if you want a client that can display all types of RDAP responses 
using a single framework.

> • Background
> • “This RFC also modifies the IANA RDAP JSON Values registry with 
> additional fields to be used in the process of presenting information about a 
> redaction, however the registry contains text intended for humans and does 
> not explicitly contain JSONPath expressions.”
> i. Correct, the RFC leverages the existing RDAP JSON Values IANA 
> registry with the new types of “redacted name”, “redacted reason”, and 
> “redacted expression language”.  The registry is meant for humans and not 
> programmatic discovery

I think you are being a bit naive here: the RDAP registry is published in CSV 
and XML formats, so the registries are clearly intended for programmatic usage. 
Otherwise, why differentiate between "registered" and "unregistered" names?

> • “clients merely rendering the values of "prePath", "postPath", or 
> "replacementPath" are of little use to most humans.”
> i. Agreed, the “name” values and especially the standard “name” 
> values, using the IANA RDAP JSON Values registry, is the most appropriate to 
> display to the end user.  The “name” values can be used by the client to 
> highlight a field displayed to the user that has been redacted, such as 
> including the “Registry Domain ID” field without a value and with red 
> strikeout text if the “Registry Domain ID” registered “name” value is 
> included in the redaction extension with a “method” value of “removal”.

Again, this assumes that the client is a tool originally designed to display 
Whois records that's being retrofitted to display RDAP records. That's not true 
of many RDAP clients.

If we are to make any progress on resolving the issues identified in Andy's 
document, we need to recognise that not all RDAP display tools are Whois 
display tools wearing RDAP trenchcoats.

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Re: regext - New Meeting Session Request for IETF 120

[Gavin Brown]

I'd like to discuss:

draft-brown-rdap-referrals-00 (15 mins)

draft-brown-rdap-ttl-extension-00 (15 mins)

Thanks,

G.

> On 3 Jun 2024, at 19:05, James Galvin  wrote:
> 
> It is a great thing that we have such interest in preparing for extended 
> technical discussions at this next REGEXT meeting.
> 
> We have until Friday, 7 June, to make adjustments to the request.
> 
> Would folks please send suggested agenda items to the list with a desire for 
> how much time you’d like to spend talking about them?
> 
> I know I have my own ideas but I do think it’s important to hear from the 
> working group first.
> 
> Antoin and I will make an adjustment to the requested time based on what 
> folks want to move forward with.
> 
> Thanks!
> 
> Jim
> 
> 
> 
> On 3 Jun 2024, at 10:40, IETF Meeting Session Request Tool wrote:
> 
>> A new meeting session request has just been submitted by Antoin Verschuren, a
>> Chair of the REGEXT Working Group.
>> 
>> 
>> -
>> Working Group Name: Registration Protocols Extensions
>> Area Name: Applications and Real-Time Area
>> Session Requester: Antoin Verschuren
>> 
>> 
>> Number of Sessions: 1
>> Length of Session(s): 2 Hours
>> Number of Attendees: 50
>> Conflicts to Avoid:
>> Chair conflict: dnsop dance saag sidrops savnet grow deleg
>> Key participant conflict: dispatch secdispatch
>> 
>> 
>> 
>> 
>> Participants who must be present:
>> 
>> Resources Requested:
>> 
>> Special Requests:
>> 
>> -
> 
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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

[regext] Re: [Ext] Re: regext - New Meeting Session Request for IETF 120

[Gavin Brown]

+1

> On 5 Jun 2024, at 09:58, Mario Loffredo 
>  wrote:
> 
> Hi Jim,
> Il 03/06/2024 20:05, James Galvin ha scritto:
>> It is a great thing that we have such interest in preparing for extended 
>> technical discussions at this next REGEXT meeting.
>> 
>> We have until Friday, 7 June, to make adjustments to the request.
>> 
>> Would folks please send suggested agenda items to the list with a desire for 
>> how much time you’d like to spend talking about them?
> Would also like to talk about the future of rdap-jscontact.
> If there is no interest from the WG in moving the document forward, have no 
> problem to drop it any time but I would like the WG to take a clear position.
> I speak on my behalf but I imagine that Gavin as co-author agrees on that.
> That said, I make some considerations here below:
> - yesterday, in his presentation [regiops.net] at ROW about WHOIS vs RDAP 
> inconsistencies, Simon Fernandez said that the jCard format is chaotic and 
> hardly parseable. This is another demontration that jCard is considered unfit 
> and we should replace it with another one more manageable.
> - in light of Andy's feedback on RFC9537 and repeating what I had already 
> written in this thread [mailarchive.ietf.org], do believe that representing 
> collections in contact data through maps instead of arrays (or worse arrays 
> of arrays) would greatly simplify the JSONPath expressions used in redaction 
> as the name selector would be mostly used in place of index selectors and 
> filters
> - the obligation/recommendation included in NIS2 about avoiding contact data 
> duplication makes me envisage that in the future we could have validated 
> contacts shared among the registries and those contacts will be likely 
> identified through universal identifiers. As a result of this, a contact data 
> format including a universal identifier could be useful.
> 
> Hope it could be helpful to resume the discussion about using JSContact or 
> any other well-structured contact data format in RDAP.
> 
> Best,
> Mario
> 
>> 
>> I know I have my own ideas but I do think it’s important to hear from the 
>> working group first.
>> 
>> Antoin and I will make an adjustment to the requested time based on what 
>> folks want to move forward with.
>> 
>> Thanks!
>> 
>> Jim
>> 
>> 
>> 
>> On 3 Jun 2024, at 10:40, IETF Meeting Session Request Tool wrote:
>> 
>> 
>>> A new meeting session request has just been submitted by Antoin Verschuren, 
>>> a
>>> Chair of the REGEXT Working Group.
>>> 
>>> 
>>> -
>>> Working Group Name: Registration Protocols Extensions
>>> Area Name: Applications and Real-Time Area
>>> Session Requester: Antoin Verschuren
>>> 
>>> 
>>> Number of Sessions: 1
>>> Length of Session(s): 2 Hours
>>> Number of Attendees: 50
>>> Conflicts to Avoid:
>>> Chair conflict: dnsop dance saag sidrops savnet grow deleg
>>> Key participant conflict: dispatch secdispatch
>>> 
>>> 
>>> 
>>> 
>>> Participants who must be present:
>>> 
>>> Resources Requested:
>>> 
>>> Special Requests:
>>> 
>>> -
>>> 
>> ___
>> regext mailing list -- regext@ietf.org
>> To unsubscribe send an email to regext-le...@ietf.org
>> 
> -- 
> Dott. Mario Loffredo
> Senior Technologist
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> Address: Via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: http://www.iit.cnr.it/mario.loffredo [iit.cnr.it]
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

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