Hello Marc,
we're working on an implementation for our gTLD registries, but there's no
"running service" available yet. We might have something available in 2-3
months time, at which point I'm happy to come back to you again to run your
clients against our "test" implementation.
Best,
Alex
-
Martin, all,
> However the drawback is that one needs to execute an actual transform
> command (ie , , , , op="request">)
> in order to obtain the balance after the transformation was executed.
I do agree with Martin that an option to gather the current account balance
without actually performi
Patrick,
> - each registry (domain names or otherwise, since RDAP applies to RIR
> also) already here on this mailing-list could contact its registrars or
> some of them, pointing them to the work here, and especially if there
> are for example EPP extensions that they plan to implement at some
>
Ulrich,
In the light of ICANN’s mandated production date for RDAP for new gTLDs (Feb
01, 2017), we are currently working on an implementation.
Alex
Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Ulrich Wisser
Gesendet: Dienstag, 13. September 2016 09:12
An: regext@ietf.org
Betreff:
Here are my raw notes:
REGEXT @ IETF 97
Jim Galvin opens the meeting - shows Note Well
Alex, Ulrich taking notes -
Jim: Small group, suffers from low review volume
Gustavo requests a few minutes to talk about "data escrow"
Existing Document status
K
I do agree we should have 2 hours, and we should use at least half of the time
on document work, maybe in smaller "interest groups". I'd specifically be
interested in progress on the Fee document.
Alex
> -Ursprüngliche Nachricht-
> Von: regext [mailto:regext-boun...@ietf.org] Im Auftra
Antoine, all,
> Facilitator: Document:
> Scott draft-hollenbeck-regext-rdap-openid
> Scott draft-hollenbeck-regext-rdap-object-tag
> Scott draft-fregly-regext-rdap-search-regex
> Roger draft-ietf-regext-epp-fees-01
I'm interested in working on the EPP-Fees
Hello all,
I'm with Antoine - i think a generic "organization" object that can fulfill
"roles" with regards to an "object" would be better than a object definition
that's only useful for one single reseller use case. Even more complicated
"chains" of resellers [rolling eyes] could be implemente
Hello Thomas,
> Generally, I wonder if this mailing list is the right place to report
> such issues. Should I rather contact the authors directly, or is there a
> bug tracker set up for this purpose?
(Disclaimer: I'm not a WG chair, personal opinion)
Generally, yes, as the document is a working
Thomas,
> What I don't like is that the "avail" attribute has been moved to the framing
> element, while it's an attribute of in the current
> fee-0.15 draft. The latter has the big advantage of the server being able to
> report e.g. the availability of a fee (and the domain in general) for
> d
Hello Roger, all,
(sorry for the crappy HTML format, my responses tagged below with "Alex>"
A few of the items that we resolved Monday include:
* Simplifying the request by removing the from the
extension. This is more in line with Option C from last year's discussions. It
does elim
[ i hate responding to my own message, but i think i need to add something ]
I wrote my message under the impression that it was suggested to change the
semantics of the "avail" flag, which is currently defined as:
The element also has an OPTIONAL "avail" attribute
which is a boolean. If
Thomas Corte wrote:
> I just realized that the agreement seems to be that it is OK to specify a
> larger fee than actually charged by the server.
Yes. And i think it's good.
> I don't think this is a good idea, I'd prefer requiring a perfect match
> of all fees. Sure, allowing the specification
James Gould wrote:
> The availability of the domain name and the availability of the fee
> information
> can be separate.
I understand that. If the *only* semantics of the "avail" attribute is to
provide the (redundant)
information that "fee" elements are contained in the "command" element, t
.
>If you have received this email in error, please immediately notify the
>sender and permanently delete the original and any copy of this message
>and its attachments.
>
>
>
>-Original Message-
>From: regext [mailto:regext-boun...@ietf.org<mailto:regext-boun.
> >> Better would be something akin to Nominet's DAC protocol:
> >>
> >> http://registrars.nominet.uk/namespace/uk/registration-and-domain-
> management/query-tools/dac/instructions
> >
For what it's worth, we (.at) use the "finger" protocol (RFC1288) for a domain
availability check:
$ finger no
Rubens Kuhl wrote:
> .br has run such an UDP-based protocol for almost 10 years... it's called
> isavail, uses UDP port 43 and implements a session cookie mechanism in
> order to enforce rate limits.
[OT] Interesting! Do you have a protocol specification available somewhere? I
can see there is so
Patrick Mevzek wrote:
> I do not agree with "the default period whould be 1 year".
> The default number of years should not be part of the protocol, since it is a
> policy item. Some registries may wish, specially at launch time, to
> use 2 years or 5 years as default period.
>
> So, please do not
Jody Kolker wrote:
> Just wondering how many registrys only accept an exact match for the fee
> currently? Dutch auction is a good argument.
We do accept any amount that is equal or higher than the required fees. I
haven't yet looked into what registrars are doing, though.
> At GoDaddy, we se
Roger,
thanks for putting the notes together. Later during the day yesterday, i came
up with a very simple requirement that i think would cover my concerns
regarding mixing in launch phases in the fee document:
- The Fee Extension MUST provide full functionality with registries
imple
Folks,
i really don’t like seeing the Fee Extension getting even more complicated than
it currently is. The „class“ of a domain is clearly an attribute of the domain
object, not the command. A *domain* is typically classified as a „Premium
Name“, not the „renew“. If a domain of that class has a
All,
i've done a review of the draft, and my comments are as follows:
I like the draft, particularly of it's simplicity and the focused
purposed. However, i find the text could be more precise in some
spots, particularly as i don't think examples consitute normative
specifications (even though mo
Hello everyone,
tl;dr - i do agree with all what Patrick said - more inline
On Fri, Aug 31, 2018 at 10:46 PM Patrick Mevzek wrote:
> And I still think it is too broad, especially "Data formats for files"
> (which files? what data? why the format needs a specification and a working
> group?).
>
Jim,
thanks for posting that - i've made my choices.
Sigh.
As i have voiced in the past, I see greatest value when the IETF standardizes
widely used protocols, *OR* important extensions to standards track protocols.
Those are the documents that directly or indirectly affect billions of int
Tobias,
Thanks for coming back to my "rant". A few observations inline:
> However, nowadays most domain registries have withdrawn to the point of
> implementing only their own ideas or approved RFCs. This inevitably leads to
> the situation that proposals for improvement - whoever they come from
Hello Tobias,
trying to settle that with a few last words:
> I think we're more or less on the same page.
[AM] Good to hear. I do agree that we have the same goal, only our paths differ
:)
> Just so we don't misunderstand each other: It's not that we or I don't
> appreciate the work on polic
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
Antoin,
I'm willing to grab 10 - 15 minutes and lead the Security Lock /
Registry Lock discussion. I have also reserved a room for a subsequent
discussion on Wednesday, 2pm (Paris) - see
https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings
best,
Alex
On Fri, Mar 1, 2019 at 5:15 PM Antoin
I've reserved room PARIS on wednesday, 2pm for that discussion. I hope
that everyone can make it - this is the "unstructured time" slot on
Wed afternoon, and so far it does not collide with any BoFs.. If
there's a more convenient time, please let me know in private mail...
i thought a doodle would
Mar 4, 2019 at 4:14 AM Alexander Mayrhofer
mailto:alex.mayrhofer.i...@gmail.com>> wrote:
I've reserved room PARIS on wednesday, 2pm for that discussion. I hope
that everyone can make it - this is the "unstructured time" slot on
Wed afternoon, and so far it does not collide w
Hello everyone,
as mentioned during the regext WG session, i've organized a "SecurityLock /
RegistryLock" side meeting. Meeting details are as follows:
- Date: Wed, 2019-03-27
- Time: 14:00 - 15:00
- Location: Room "Paris" at the IETF venue
Unfortunately, remote pa
lex
Von: Alexander Mayrhofer
Gesendet: Dienstag, 26. März 2019 11:13
An: regext@ietf.org
Betreff: Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00, Room Paris
Hello everyone,
as mentioned during the regext WG session, i've organized a "SecurityLock /
RegistryLock" side meeting
Hello everyone,
we've recently done some work on a tool that suggests domain names to
registrants if their desired name is already taken. The primary focus
is now using it on our website, but a subsequent step would be
providing an API for registrars so that they can integrate it into
their websit
t the
idea.
As always - feedback highly appreciated!
best,
Alex
-- Forwarded message -
From:
Date: Fri, Nov 1, 2019 at 8:57 PM
Subject: New Version Notification for draft-mayrhofer-epp-domain-suggest-00.txt
To: Alexander Mayrhofer
A new version of I-D, draft-mayrhofer-epp-do
Hello Patrick,
thanks for the very fast feedback. Responses inline:
On Fri, Nov 1, 2019 at 9:15 PM Patrick Mevzek wrote:
> > As always - feedback highly appreciated!
>
> 3 quick ones more on the form than the substance:
>
> - did you look at other extensions existing?
> I know at least about one
Hello everyone,
I've promised to organize a small side meeting regarding Domain Name
Suggestion APIs and standardization potential. Given the topic is also
on the regext agenda, i really want it before the regex WG session.
We'll meet:
- When: Tuesday, Nov 19th, 09:00 - 09:45
- Where: Olivia (did
Hello everyone,
Ulrich has published a new revision of his registry lock draft
(draft-wisser-registrylock). We're currently in the process of evaluating
whether that draft would fit into a) our processes and b) the need of our
registrars. We do - of course - want to avoid introducing any "weird
Hello Scott,
> -Ursprüngliche Nachricht-
> Von: regext Im Auftrag von Hollenbeck, Scott
> Betreff: [regext] Virtual Interim Meeting Question: and in
> rfc7482bis
[AM] My point was that the text on the slide...
> "Syntax: domains?nsLdhName =
> Syntax: domains?nsIp = is a s
Jim, Antoin,
I can do the note-taking during the meeting. And I'm happy to use codimd.
Best,
Alex
> -Ursprüngliche Nachricht-
> Von: regext Im Auftrag von James Galvin
> Gesendet: Montag, 16. November 2020 10:45
> An: Registration Protocols Extensions WG
> Betreff: [regext] IETF109 -
Jumping into this discussion quite late, but...
On Thu, Nov 19, 2020 at 4:39 PM Gould, James
wrote:
> The 3 options presented and discussed at the REGEXT meeting included three
> extension options, which all include an namespace URI in the greeting and
> logic services:
I'd really like to und
Mario, all,
i'm currently implementing a prototype RDAP server that uses sorting and
paging features. I've gotten so far to implement the basic parameters
(cursor in the limit/offset variant, and sort), and now i'm trying to
implement the "paging_metadata" elements. I have a few comments on that
(
Hi,
i support adoption of this document, the changes between RFC7484 and
this version of this draft look good to me.
best,
Alex
On Mon, Jan 18, 2021 at 3:29 PM James Galvin wrote:
>
> This is a formal adoption request for “Finding the Authoritative
> Registration Data (RDAP) Service”:
>
> https
I do support adoption of this document, and I am willing to perform reviews and
text.
Best,
Alex
> -Ursprüngliche Nachricht-
> Von: regext Im Auftrag von James Galvin
> Gesendet: Montag, 18. Jänner 2021 15:29
> An: REGEXT WG
> Betreff: [regext] CALL FOR ADOPTION: draft-loffredo-regext
Guys,
i’ve yet to read up on the latest version of the document (and I will do so).
However, as a quick comment:
1. Establish TCP connection
2. Establish TLS session via TLS-handshake
3. Establish HTTP session via setup of the HTTP session cookie (e.g.,
JSESSIONID)
4. Return EPP Gr
44 matches
Mail list logo
