[{"author": "Jody Kolker", "text": "

Test

", "time": "2024-03-19T23:31:21Z"}, {"author": "Richard Wilhelm", "text": "

I'm in the notes real-time... others happy to join if ya want

", "time": "2024-03-19T23:35:58Z"}, {"author": "George Michaelson", "text": "

Would I be right in thinking this has interest for ICANN tech compliance because of universal acceptance? (intl emails)

", "time": "2024-03-19T23:38:27Z"}, {"author": "Arnt Gulbrandsen", "text": "

I work with UA at ICANN; it has interest of course but not relevantly to the issues that have held this up.

", "time": "2024-03-19T23:43:30Z"}, {"author": "Richard Wilhelm", "text": "

Gavin, I'll be providing some feedback within the next week (on the list)

", "time": "2024-03-19T23:46:57Z"}, {"author": "James Gould", "text": "

Great work Gavin!

", "time": "2024-03-19T23:47:08Z"}, {"author": "Richard Wilhelm", "text": "

but I expect it to be just tune-up/polishing sort of feedback

", "time": "2024-03-19T23:47:10Z"}, {"author": "James Gould", "text": "

Thanks, I look forward to your response to the feedback.

", "time": "2024-03-19T23:53:11Z"}, {"author": "Ties de Kock", "text": "

geofeed is inherently linked to internet numbers

", "time": "2024-03-19T23:56:21Z"}, {"author": "Ties de Kock", "text": "

I am not aware of the signing in rfc9092 being used in practice

", "time": "2024-03-19T23:56:48Z"}, {"author": "James Gould", "text": "

Let Rick go first

", "time": "2024-03-20T00:10:40Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

3.2 of draft-ietf-regext-rdap-versioning adresses the same problem and this we should tackle

", "time": "2024-03-20T00:24:15Z"}, {"author": "James Gould", "text": "

In the versioning draft the client can specify what they want via the query parameter or via the media x. The server must support both forms.

", "time": "2024-03-20T00:24:23Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

@James, right but do we need the complexity of 2 distinct ways of doing the same thing?

", "time": "2024-03-20T00:25:43Z"}, {"author": "James Gould", "text": "

I believe the media x addresses the redirection services and the query parameter can be directly invoked for clients that aren't passing through a redirection service. I find the query parameter to be simpler if directly interfacing with the server, but we want to also support redirection services.

", "time": "2024-03-20T00:26:57Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

... if the browser is considered as a client... which is not the best ever tool to read json IMHO

", "time": "2024-03-20T00:29:27Z"}, {"author": "Ties de Kock", "text": "

James: My understanding is that the media type selection with query parameters silently disappear if your request ends up being redirected? That is a property that I would dislike as a user

", "time": "2024-03-20T00:31:03Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Pawel I like the JSON support in Firefox

", "time": "2024-03-20T00:32:39Z"}, {"author": "Nigel Hickson", "text": "

This was most interesting; thanks

", "time": "2024-03-20T00:33:00Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

@St\u00e9phane I like it too, nice exception does not set the rule in my eyes. I still consider RDAP to be more of an API rather than something a human would interact with directly as a primary use case.

", "time": "2024-03-20T00:36:52Z"}, {"author": "Stefan Ubbink", "text": "

I wouldn't think of looking at RDAP when debugging a DNS (TTL) issue

", "time": "2024-03-20T00:37:40Z"}, {"author": "Kal Feher", "text": "

agree with @James Gould , DNS should be authoritative for DNS material. RDDS systems can be disconnected from from the registry, so it is not necessarily giving you an insight into what the registry thinks is the truth.

", "time": "2024-03-20T00:37:51Z"}, {"author": "James Galvin", "text": "

From my point of view, the ability to query TTL values in the registry is valuable because it is a value that is in the registry. a registrant interacts with the registrar but regardless of what the registrar does on behalf of the registrant, the actual setting is subject to registry policy and it's therefore useful for the registrant (or anyone) to be able to check this.

", "time": "2024-03-20T00:40:25Z"}, {"author": "Kal Feher", "text": "

I find myself using RDDS to debug Registrar <-> Registry different versions of the truth. but never Registry <-> DNS

", "time": "2024-03-20T00:40:38Z"}, {"author": "James Galvin", "text": "

It's not about DNS. it's about confirming what the registry thinks.

", "time": "2024-03-20T00:41:17Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Kal Strong disagree. For security reasons, it is very important to check that the registry and the DNS agree, at least for important data (NS, glue, probably not TTL).

", "time": "2024-03-20T00:41:53Z"}, {"author": "Jim Reid", "text": "

IMO, what the registry thinks is the truth doesn't matter. We're just allowing TTLs reflect the child's preference rather than the registry's default.

", "time": "2024-03-20T00:41:54Z"}, {"author": "Andrew Newton", "text": "

It is really about the registry database and not DNS

", "time": "2024-03-20T00:42:18Z"}, {"author": "Jim Reid", "text": "

As long as the TTL works, who cares how long it is?

", "time": "2024-03-20T00:43:04Z"}, {"author": "Andrew Newton", "text": "

It matters when you are trying to change it.

", "time": "2024-03-20T00:43:51Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

+1 to the opinion of James Galvin

", "time": "2024-03-20T00:44:35Z"}, {"author": "Kal Feher", "text": "

@St\u00e9phane Bortzmeyer my point is that RDDS is _not_ the registry. if there is a disconnect between what you think should be in the DNS and DNS, then RDDS is a hint, but not strictly the truth in all cases.

", "time": "2024-03-20T00:44:52Z"}, {"author": "Andrew Newton", "text": "

@Jim Reid are you saying DELEG won't have TTL values?

", "time": "2024-03-20T00:45:21Z"}, {"author": "James Galvin", "text": "

Jim Reid asks a fair question. Similarly, I do understand where Kal is coming from.

", "time": "2024-03-20T00:45:33Z"}, {"author": "James Galvin", "text": "

I don't feel strongly either way. I do see value in ensuring it can be queried because it is a check on the registry system.

", "time": "2024-03-20T00:46:02Z"}, {"author": "Jim Reid", "text": "

It will Andy. So why argue now about NS TTLs when DELEG TTLs are just around the corner>

", "time": "2024-03-20T00:46:10Z"}, {"author": "George Michaelson", "text": "

what if.. we set the values in EPP based on whats seen in the DNS and not the other way round? I want to confront the implicit belief EPP is canonical always. and \"sets\" the value(s) in DNS. Maybe registry has to follow DNS not define it?

", "time": "2024-03-20T00:46:19Z"}, {"author": "Jim Reid", "text": "

s/>/?/ - fat fingers

", "time": "2024-03-20T00:46:30Z"}, {"author": "George Michaelson", "text": "

(appreciate thats not how it works right now)

", "time": "2024-03-20T00:46:38Z"}, {"author": "Jody Kolker", "text": "

I don't see an issue with TTL added to RDAP.

", "time": "2024-03-20T00:46:52Z"}, {"author": "James Galvin", "text": "

Frankly, why does the registry return anything in the registration data since really only the registrar cares about it? That's the logical conclusion, in my mind, of this discussion about responding with the TTL.

", "time": "2024-03-20T00:46:57Z"}, {"author": "Andrew Newton", "text": "

@Jim Reid it is my understanding that this draft would work with DELEG.

", "time": "2024-03-20T00:47:24Z"}, {"author": "Jim Reid", "text": "

George, the domain might not be in the DNS until the registry has delegated it.

", "time": "2024-03-20T00:47:48Z"}, {"author": "James Galvin", "text": "

My strong position is consistency. If we don't want the TTL then we need to undo NS and DS.

", "time": "2024-03-20T00:48:07Z"}, {"author": "Stefan Ubbink", "text": "

should we already see the DELEG slides? I still see the TTL Why slide

", "time": "2024-03-20T00:49:55Z"}, {"author": "George Michaelson", "text": "

@jim sure, there's that side of priming state but after that, with DELEG a lot of information which we might want to \"check\" will not be in registry unless we make registry follow what is said parent-child

", "time": "2024-03-20T00:49:58Z"}, {"author": "Andrew Newton", "text": "

I don't see the DELEG slides either

", "time": "2024-03-20T00:50:15Z"}, {"author": "Ties de Kock", "text": "

@GGM: Isn't it also a question about what component has the source of truth? With DELEG the parent will not be the source of truth anymore. Even when debugging the only definite information the parent has is \"well it points there\"?

", "time": "2024-03-20T00:51:50Z"}, {"author": "Kal Feher", "text": "

Any DNS data in RDDS is incongruous. I think we are making the incorrect assumption that RDDS _is_ the registry, when in fact it might be derived.

", "time": "2024-03-20T00:53:34Z"}, {"author": "Andrew Newton", "text": "

@George Michaelson interesting point... so to get the info that is to be checked does that mean the parent will be scanning children?

", "time": "2024-03-20T00:55:20Z"}, {"author": "James Galvin", "text": "

@George One possibility with DELEG is, as you say, the registry doesn't have the information and thus there's no information in the response. With DELEG the registry would be out of the loop, right?

", "time": "2024-03-20T00:57:14Z"}, {"author": "Jim Reid", "text": "

Andy, of course the draft should work for DELEG. If it was mentioned in the doc. :-) My point was not to rush the standardisation of this ID because work on DELEG is just about to get under way. ie get one doc which covers TTLs for all delegation metadata. For some definitions of \"all\" and \"metadata\".

", "time": "2024-03-20T00:58:41Z"}, {"author": "Jody Kolker", "text": "

How would the fee extension be mapped to the REST implementation?

", "time": "2024-03-20T00:59:45Z"}, {"author": "George Michaelson", "text": "

@andy generalised NOTIFY I hope

", "time": "2024-03-20T01:02:03Z"}, {"author": "George Michaelson", "text": "

@james yes there is a lot of that in this. It may become contentious

", "time": "2024-03-20T01:02:19Z"}, {"author": "Gavin Brown", "text": "

+1. This isn't EPP, it's something else

", "time": "2024-03-20T01:04:11Z"}, {"author": "James Gould", "text": "

+1, this is another provisioning protocol.

", "time": "2024-03-20T01:04:45Z"}, {"author": "Murray Kucherawy", "text": "

It's only a question for Murray for about the next eight hours.

", "time": "2024-03-20T01:05:36Z"}, {"author": "Murray Kucherawy", "text": "

But if you want an opinion ...

", "time": "2024-03-20T01:06:02Z"}, {"author": "Orie Steele", "text": "

I'd like one

", "time": "2024-03-20T01:06:09Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

I think was was presented is fully in line with the discussion we had in Prague with a large support from the group to experiment with this path.

", "time": "2024-03-20T01:08:51Z"}, {"author": "Murray Kucherawy", "text": "

Shooting from the hip:

\n

It exceeds the charter because it's transport, not a data extension.

\n

That doesn't mean it's a bad idea. If we think this would benefit the ecosystem, we can talk about whether REGEXT should expand to cover it, or do it somewhere else, or sponsor it, or what.

", "time": "2024-03-20T01:09:31Z"}, {"author": "Andrew Newton", "text": "

That same line of reasoning means the other approaches (HTTP and QUIC) are also out of scope of the charter.

", "time": "2024-03-20T01:10:13Z"}, {"author": "James Gould", "text": "

How would defining a new EPP transport compliant with RFC 5730 be considered out-of-scope with the charter. We should review the language in the charter.

", "time": "2024-03-20T01:11:26Z"}, {"author": "Ties de Kock", "text": "

EPP Transport and API shape (REST) are orthogonal concerns? With one being a bigger change than the other?

", "time": "2024-03-20T01:11:51Z"}, {"author": "Kal Feher", "text": "

+1 to @Andrew Newton's point. but also noting that the very small ecosystem of interested ppl is here

", "time": "2024-03-20T01:12:00Z"}, {"author": "Andrew Newton", "text": "

agreed that EoH is an easier transition but if we want to play IETF charter layer, then none of these are \"extensions\".

", "time": "2024-03-20T01:13:50Z"}, {"author": "Richard Wilhelm", "text": "

I'll take it offline

", "time": "2024-03-20T01:13:58Z"}, {"author": "Richard Wilhelm", "text": "

no worries

", "time": "2024-03-20T01:13:59Z"}, {"author": "James Gould", "text": "

Let's look at the language in the charter.

", "time": "2024-03-20T01:14:32Z"}, {"author": "George Michaelson", "text": "

aargh charter wars are the worst wars. can we do good work instead (sigh)

", "time": "2024-03-20T01:15:23Z"}, {"author": "George Michaelson", "text": "

chairs gotta chair I guess

", "time": "2024-03-20T01:15:34Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

+1

", "time": "2024-03-20T01:15:51Z"}, {"author": "James Gould", "text": "

The URL is defined by the server

", "time": "2024-03-20T01:17:14Z"}, {"author": "James Gould", "text": "

The URL is similar to the host name of the server being connected to via TCP. The HTTP GET maps to the TCP connect.

", "time": "2024-03-20T01:18:48Z"}, {"author": "James Gould", "text": "

I would define the transports as an extension, since the extension mechanisms are defined in RFC 5730. RFC 5730 states \"EPP is a stateful XML protocol that can be layered over multiple transport protocols.\"

", "time": "2024-03-20T01:22:40Z"}, {"author": "James Gould", "text": "

In addition there is section 2.1 for RFC 5730 for the definition of new transports. This is a form of extension of EPP.

", "time": "2024-03-20T01:23:30Z"}, {"author": "Orie Steele", "text": "

Thanks James

", "time": "2024-03-20T01:26:32Z"}, {"author": "John Klensin", "text": "

As an outsider, I'm finding separate specifications for each imaginable transport very confusing. Is \"EPP over Avian Carriers\" next, followed by \"EPP over Aquatic Mammals\", etc.? From an architectural standpoint, If EPP itself is that transport-sensitive, doesn't that suggest a fundamental problem with EPP?

", "time": "2024-03-20T01:27:18Z"}, {"author": "Maarten Wullink", "text": "

calling new transport an extension is confusing i think. because its nog and extension of the xml schema

", "time": "2024-03-20T01:27:26Z"}, {"author": "Murray Kucherawy", "text": "

Same question about transport, I guess.

", "time": "2024-03-20T01:28:15Z"}, {"author": "Maarten Wullink", "text": "

is not an extension

", "time": "2024-03-20T01:28:18Z"}, {"author": "Orie Steele", "text": "

See this section here: https://datatracker.ietf.org/doc/html/rfc5730#section-2.1

", "time": "2024-03-20T01:28:24Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@Scott The client typically configures the EPP session manually. So, choosing the transport based on out-of-band information is OK.

", "time": "2024-03-20T01:30:01Z"}, {"author": "George Michaelson", "text": "

@john strong agree

", "time": "2024-03-20T01:30:43Z"}, {"author": "John Klensin", "text": "

Orie, understood, but I'm asking a more basic questions as that section plays out. Do you want specification proposals for every single application protocol that simply assumed TCP (or IP, or QUIC, or???)

", "time": "2024-03-20T01:30:54Z"}, {"author": "Andrew Newton", "text": "

So if they are extensions, are they registered in the EPP extension registry?

", "time": "2024-03-20T01:31:15Z"}, {"author": "Orie Steele", "text": "

which concrete transports exist for EPP today?

", "time": "2024-03-20T01:31:32Z"}, {"author": "Andrew Newton", "text": "

None

", "time": "2024-03-20T01:31:42Z"}, {"author": "Orie Steele", "text": "

hmm, ok, well then also shooting from the hip, lets revist the charter before considering if a new transport is in scope.

", "time": "2024-03-20T01:32:49Z"}, {"author": "Mario Loffredo", "text": "

@Andy They are not extensions, they are mapping just like EoT as defined in RFC 5730

", "time": "2024-03-20T01:32:52Z"}, {"author": "Kal Feher", "text": "

so the intent of this DELEG doc is to shadow the developments in the DELEG (not yet existing.. ) WG?

", "time": "2024-03-20T01:32:57Z"}, {"author": "Andrew Newton", "text": "

I am not against defining new EPP transports, but I think trying to thread the needle where some are in charter and some are not is not a good way to have this discussion.

", "time": "2024-03-20T01:33:02Z"}, {"author": "James Gould", "text": "

EPP only has a single EPP over TCP (EoT) transport defined in RFC 5734. EoT was used as a template to define EoH and EoQ.

", "time": "2024-03-20T01:33:48Z"}, {"author": "Gavin Brown", "text": "

thank you Murray!

", "time": "2024-03-20T01:34:09Z"}, {"author": "James Gould", "text": "

Yes, thank you Murray!

", "time": "2024-03-20T01:34:20Z"}, {"author": "Pawe\u0142 Kowalik", "text": "

thank you Murray

", "time": "2024-03-20T01:34:24Z"}, {"author": "Marco Davids", "text": "

Groetjes, Antoin!

", "time": "2024-03-20T01:34:57Z"}]