ms to do.
My 2 cents.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
people do things differently/with more caution?
I think the second case can be done, but not really the first.
And even so, it is maybe out of IETF scope as it is more an operational matter
than really a problem in the protocol itself.
--
Patrick Mevzek
p...@dotandco.com
both NS/A/ and DS?
If I take `.com` right now, NS has 2 days of TTL, where DS only one day.
Curious of registries views on that.
HTH,
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
hanges to address my previous comments.
+1 on the document going forward.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ribing a
protocol
should lay any assumption or give constraints on how implementers decide to
implement it.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
m from the beginning".
Just my personal views of course.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t can
consult the certificate given.
It can be considered a weak or partial authentication, until the EPP login
is successfully executed.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
will anyway need to handle that on their end in some cases, so they should
just be prepared to do it for all cases, and hence no extra new work needed
for any servers.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
by domain name registrars and registries, EPP/RDAP
are used for things that are not related to the DNS at all (ex: contacts).
Second because EPP was created as a generic provisioning protocol that
technically could handle things completely unrelated to domain names,
even if it is its only major
fact
to know if that is really a factor for them.
Third, for any registrar stack, adding a new "client" for RDAP stuff
may be easier than changing their EPP stack to add yet one more extension.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
rs.
I think the authentication/authorization stuff is orthogonal to the features
provided
by the protocol.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ve or change public key material (e.g., DNSKEY or DS
resource records) on behalf of customers to the Registries that support DNSSEC."
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
the server needs to use when constructing some reply.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
s down the line.
> I wish that ICANN/Universal Acceptance people would participate in this
> discussion.
+1, but also noting of course the issue may be more "pressing"/urgent in case
of some IDN ccTLDs than gTLDs.
--
Patrick Mevzek
p...@dotandco.com
_
r "Informational".
Without any clear signal we would have just to infer things based on who
interacts
on the subject and opinions expressed. And right now I don't see a clear signal
on going ahead with placeholders, the discussion seems pretty mixed on the
issue.
--
Pat
as many similar cases as possible, to lower
risks of fragmentation.
Also all of this is obviously related to Universal Acceptance, and at least in
gTLD
world, ICANN has a specific team/workgroup on that subject.
--
Patrick Mevzek
p...@dotandco.com
___
see how they work.
Another options is to first document the problem and constraints space, and then
in a separate document offer a solution.
Making everyone first agreeing exactly on what problems need to be solved
can frame discussions efficiently.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ot disrupt all other
registrars NOT wanting to support this scenario.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to sell their TLDs, which can be fine or not, but a
problem
for the registry to decide and for which this protocol called EPP can not do
anything.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to email addresses.
Long gone are the days when only an email sent was enough to trigger a transfer,
and for good reasons.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t breaking current software but 2)
allows
updated software to enjoy more features)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to reject things if only because the new
one can not handle something.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ided or only the one to
change,
I don't know).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
s namespaces X, Y, Z and registrars
have to deal with them somehow"?
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
der, like it was done for login-security
seems to me just a poor way to try doing basically whatever XML namespaces
are trying to do without doing it properly.
I sincerely do not hope this is the way things are going
(speaking as an implementer of multiple EPP servers and clients).
--
Patrick M
't be
aware
of the change.
That is exactly the risk, because the change is not 100% aligned with what was
in past specifications.
As I said already I don't think there is pretty much anything else/again to
discuss.
The consensus is clear considering the silent m
e responsibility clearly
falls on his end and he is in control of his fate because he signaled the
namespaces
at login, without the registry forcing delivery to it of messages with "dubious"
validity per RFC 5730).
--
Patrick Mevzek
p...@dotandco.com
_
ent of extValue, and possibly having value/extValue with NON error codes)
Your draft *clearly* creates a _risk_ for any existing client starting to break
once a server enables this feature. Saying that one client works fine is
not a measure of interoperability risks when it is
t all
clients will suddenly
be upgraded to use this specification (as if all EPP servers out there will
be updated...), then so be it, it does not really matter.
Again, I am not trying to convince anyone, I know it won't happen,
I just phrased my justifications on the problems I see.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
that new view on them, without any possible negotiation.
At this point it seems we are just repeating our own arguments on both side,
so I don't think either will move their position and we have to keep our
disagreement, which is fine.
I wanted to record my disagreement on this draft during
t should certainly not be "Best Current Practice".
It is neither proved to be "best" nor is it "current practice".
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
P track or if you believe a different track
> should be used for one or both drafts.
I believe they both should be "Experimental" instead.
They are not long term widespread "current practices" at all.
As for "best" ones, I
2 already has "The RDAP service MUST be provided over HTTPS only."
so that will already cover a not small amount of entries in the bootstrap
registry.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://w
://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml#rdap-extensions-1
- arin_originas0
- artRecord
- cidr0
- fred
- icann_rdap_response_profile_0
- icann_rdap_technical_implementation_guide_0
- platformNS
- rdap_objectTag
- regType
It would be very good hence to see there also r
Hello Marc,
On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
> >
> > PS: related but not directly, at least for domain registries, it would
> > be
> > nice to have an `SRV` record on `_rdap._tcp` or something to poin
data,
which also removes IANA from the hot operational path when RDAP clients do
queries.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
recall correctly.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
pported
> extensions that are available to that client.
Yes, the help response allows to "discover" all possible extensions from a
specific client.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
matter of
> server policy.
If you introduce options (the list is either related to the content OR the full
list of server features), how is a client supposed to know in which case he is?
He can't right now,
which is why I don't think such options should be added.
--
P
Considering that, in the future, for the same query, the reply can be different
based on the client and its level of access.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ole ecosystem.
(the last one transitioning and finally removing the old version completely from
all systems may be even the one with the highest benefit to the community).
But in short, no one gets benefit of starting first.
Hence, outside forces need to come into play to tilt the current balanc
ease" framework, but I am really
not sold that any technical solution can solve the problem there.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e RDAP
protocol and of any extensions, as specified in RFC7483.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ht after creation and creation only.
This is for me more policy stuff (and good registry documentation would specify
that somewhere, even if I bet it doesn't happen), as it has no real consequences
on the protocol or interoperability matters.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
I do not think that "MUST NOT exceed 1024 bit." is
the adequate description for a string of characters.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
On Mon, Apr 27, 2020, at 11:46, Mario Loffredo wrote:
> Il 27/04/2020 08:04, Patrick Mevzek ha scritto:
> > Also:
> > couldn't each fieldset have a list of jsonPath elements (similar to what is
> > done in
> > draft-ietf-regext-rdap-sorting-and-paging)
> >
On Mon, Apr 27, 2020, at 06:27, Hollenbeck, Scott wrote:
> > -Original Message-
> > From: regext On Behalf Of Patrick Mevzek
> > Sent: Monday, April 27, 2020 4:06 AM
> > To: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck
Hello Mario,
A quick follow-up that could be a closure in fact, as your answer fills
the missing points I had.
On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote:
> Il 27/04/2020 07:45, Patrick Mevzek ha scritto:
> >
> > On Fri, Feb 28, 2020, at 09:43, Antoin Verschuren
483].
"
Shouldn't RFC7483 be replaced by the draft rfc7483bis?
PS: there is currently a problem in the tracker,
on https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
a version 03 is shown as existing but you can't vie
009.pdf
(both do an automatic redirect from http:// to https:// anyway)
And with all planned changes to RFC7483, it is time to introduce
rdap_level_1
in rdapConformance values?
If we say: "we shouldn't because clients will not be upgra
s the URI associated with the entire HTML document. "
There is no real explanation of the context for RDAP, but based on that maybe
it should be a link to the same query with fieldSet "full"?
On Mon, Apr 27, 2020, at 00:45, Patrick Mevzek wrote:
>
>
> On Fri, Feb 28, 2020
be multiple drafts in fact for multiple definitions.
PS: the argument in A.1 about the complexity arising out of jCard can "soon"
become obsolete if draft-loffredo-regext-rdap-jcard-deprecation goes through,
so maybe some text should have addressed other non jCard cases (or explaining
why
ext, not 1024 bit (sic).
Also, I see no reason for this limit, can you care to explain why description
content, being freeform for human consumption, should be limited at the
protocol level?
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
On Mon, Mar 16, 2020, at 09:28, Gould, James wrote:
>
> One question that was raised by Patrick Mevzek on the mailing list was
> associated with signaling the implementation of a BCP by the server
> that I believe would also apply to the client. This question applies to
> the
On Thu, Jan 23, 2020, at 01:01, Patrick Mevzek wrote:
> 2) for the login security draft I said from the beginning that instead
> of just relaxing the limits on password length, we may want to use
> more standardized methods such as SASL, and in particular there are mechanisms
> to
ap-deployfindings)
as I have not being able yet to release anything for my own free one under free
time.
But not sure it would add value to the document. We can discuss that separately.
--
Patrick Mevzek
p...@dotandco.com
___
regext ma
n bothering sending it?
I will leave it at that for now, and see further discussions if the
draft is adopted by the working group.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
onses, and no document, even BCP, will make
registries change behavior, if there are no good reasons/generic
framework/clear push
from registrars that are very silent in this WG/etc.
Maybe at some point, as controversial it might be, it would make sense to start
working
on "epp-2.0" or
s
attached to the domain, or its expiration, etc.)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
draft as it stands completely address the issue.
[1] TL;DR: a registrar has no way to automatically discover
a registry is using the mechanism outlined in this document,
as not announced in the greeting part.
--
Patrick Mevzek
p...@dotandco.com
___
r
.
Unfortunately.
Or fortunately :-)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
etf:params:xml:ns:idn-1.0
See the lack of version numbers in the schema URI provided,
but not for all of them :-).
This can be deemed a direct violation of the protocol,
but registrars still have to deal with it in some way.
--
Patrick Mevzek
p...@dotandco.com
__
Hello Scott,
On Fri, Dec 20, 2019, at 13:04, Hollenbeck, Scott wrote:
> > -Original Message-
> > From: regext On Behalf Of Patrick Mevzek
> > Sent: Friday, December 20, 2019 12:14 PM
> > To: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] How to h
how many
hitpoints it has.
And the above list is far from being exhaustive...
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
security.
I remain in another side: other solutions, instead of passwords, should be
found.
Continuing to use passwords when other (better) solutions exist is not an effort
I find useful.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
ep their own
database in sync.
> However many clients seem to send
> just about always and they would need to adjust.
There are as many broken clients as they are broken servers...
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing l
with various warts the current situation.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to happen
earlier,
but that is the past behind us.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
of security) but not with the mean (I think we
must go further than just allowing longer passwords, just this adds only
marginal extra security by itself).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
r
(no matter what the transport; and do remember that EPP ought to be transport
agnostic, and there were attempts in the past to have it over SMTP for example,
in fact at least one registry has it that way nowadays...)
--
Patrick Mevzek
p...@dotandco.com
_
ust making sure
you handle as little sensitive information as needed, and then secure the rest.
Having clear text passwords at the protocol level is definitively not
a MUST for the protocol to work correctly, the protocol could work with other
ways
to authenticate, eliminating the sensitive part of the in
am interested to work on this if anyone else is also. I might try to offer
a proposal at some point, not sure.
During discussions of this draft, I pointed to SASL for the extensibility it
provides,
but this was apparently not a good fit for this specific extension.
--
Patrick Mevzek
o that you have at least a timestamp. IANA registration could at
least include a timestamp (when the extension was registered)
PS2: seeing that all of the above come from the fact that we are basically
trying to reinvent XML namespaces but in JSON... and arriving at the situation
where we get al
the
issue again, I was just leaning towards Barry's opinion that the constraints are
"strange" (yes they come from the XML schema datatypes, but that does not define
the semantic of the field, which is not just an XML token, but really a
password,
which is all the discussion of PRECIS
rious
non-ASCII space code points, many of which are difficult to
reproduce across different input methods.
(note also RFC8264 §5.3 for a discussion about spaces)
I am still of the opinion that we should have used/referenced that work more.
--
Patrick Mevzek
p...@dotandco.com
eneric Registry-Registrar Protocol Requirements"
or
RFC 7485 "Inventory and Analysis of WHOIS Registration Objects"
that were written before any work took place.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
is fine. But clearly bike shedding at
this point.
Will try to read the draft more deeply later for substantive feedback, if any.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
S from DNSSEC.
- please stick to RFC2606 when choosing names for examples (ie: do not use the
TLD .tld)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
a specific time window.
The biggest drawback is that in this scheme the current registrar may not have
any
explicit guaranteed way to oppose any outgoing transfer (because some changes
outside of
it could be enough to authorize the transfer)... except that is what
the status clientTransferProhi
me criteria to help in future cases) is of
interest
to anybody and some work is started on it, I would be interested to join this
effort.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
think the contact information comes because of §3.1
So it seems useful to have, but then why not say contact information is useful
for all other bootstrap documents (domain, IPv4, IPv6, etc.) also?
This would mean an 7484-bis, so again quite some work.
What do people havi
d in RFC
2026 [1] with a two-tier maturity ladder. Specifications become
Internet Standards through a set of two maturity levels known as the
"Standards Track". These maturity levels are "Proposed Standard" and
"Internet Standard".
--
Patrick Mevzek
even the IETF. It may be a better fit for some ICANN groups, in order
to deliver some "consensus policies" document (but remembering also at the same
time that there is a world outside of gTLDs). In my view the whole process
around
tr
r not.
But I would at least suggest that the draft is clearer on what it defines,
policy or format.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ing, that specific behavior I described existed but ceased
to recently when the registry changed its backend (now any single
operation on a domain in a bundle does the same operation for all other
domains in the bundle - that clearly solves the "batch" problem but then
exposes to
tries to take into account all existing
cases in the wild, not a subset of them. I have tried to show that the draft
presented
just forgets about existing cases, which could hinder its wide adoption.
--
Patrick Mevzek
p...@dotandco.com
___
rege
t decide per local
policies?
- a mention/discussion of RFC7613 would seem appropriate
- more generally working today on authentication should be based on SASL and
we should open things better and with more extensibility. This extension is just
piggybacking on the current scheme which creates its own range
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.
-dataset/
>
> Information about remote participation:
> https://godaddy.zoom.us/j/958439027
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
--
Patrick Mevzek
p...@dotandco.com
_
n
> external resource (e.g., url) that defines the password policy
> information?
That would then be only for human consumption, an EPP client won't be doing
anything with it, so providing that URL through EPP does not provide any gain
I b
s not dealing with only one gTLD
(because even if it exists I doubt that one could mandate all gTLD registries
to accept this CA and only this CA as it is a matter of trust and transitive
trust, so why should any gTLD registry trust unconditionnaly this new CA?)
--
Patrick
rching on the obvious title.
Thanks in advance,
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
they can not use it in their case). This is exactly
why the world of EPP extensions is so fragmented. But I will rest my case here.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
om the Unicode Latin script
- at least one uppercase, one lowercase, one digit, and one punctuation
character (in no specific order)
- no repeated sequence of two or more characters
- no given character repeated in sequence
- between 17 and 33 characters long in total
--
Patrick Mevz
n other cases, it would be good to see other registries/registrars voice
their opinion, or even better implement it or something else or explicitely not
for some reasons, etc.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
nsion risks
for now the fact that not a lot of registries will implement it.
Each extension should try to stand-alone as much as possible...
Otherwise in your current setup a registry needs to implement this extension,
the core policy one, and then the extension on the policy one. I have low h
rent greeting/login).
Like SRP and the example of RFC5054 "Using the Secure Remote Password (SRP)
Protocol for TLS Authentication".
Or at least, like I suggested on the policy extension, but that was not meant
with a lot of enthusiasm, to implement S
same problem of (non technical but possible
confusing) collision.
And more generally, "tech" is too short to convey enough meaning just by itself.
In general I also fail to see what we gain by using short names.
Why not application, technology and ope
on "postalAddr", etc.
And again, if a new contact schema appears, registries that want it use it,
those that want to keep the current contact-1.0 keep it, and all is fine
(besides the complexities for registrars, but obviously they will have
to deal with it in any way, placeholders introduce their own complexities
as they will be hardcoded in every piece of code, so that the value is
not offered for edition for example, etc.)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e amount of work, but second option seems better to me
for multiple reasons.
And again, there is a huge non technical difference.
If we give again the impression to change the EPP just to suite gTLD needs,
we should not lament later on the state of EPP worldwide and why not everyone
follows the sta
1 - 100 of 247 matches
Mail list logo
