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
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
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
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
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
ms to do.
My 2 cents.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
isign_epp-extension_balance_v00.html
Why not keep the 2 aspects (fee & balance) separated ?
Since there are registries not using a prepayment model, hence where
the balance has no meaning, but the fee part is useful.
--
Patrick Mevzek
___
regext
r activity.
Hence my question on the 2 possible interpretations above and basically
if the presence of the grace-period attribute implies the presence of
the refundable attribute with some value?
TIA,
--
Patrick Mevzek
___
regext mailing list
regex
m the
transformCommandType ?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
er
replies, the text in §2.1 does not explain what the server
could/should reply, as it is written only from the registrar
perspective. Could you elaborate which specific cases the server might
use?
- there are no examples of the third case of §2.1, that is flag=0 + no
exDate node. Could you
update command)
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
istries should reply with its default value (the same one
that will be used during a domain:create or other commands without a
domain:period), which can be any number based on local policies
(and may be different depending on the commands, it can be 2 years for
create, but 1 for transfe
implement it.
So, just a thought if it can help, complementary to all other
initiatives that may foster participation.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
(and I've not said it at the mike then, but it was in fact draft-brown-
domain-pricing, not submitted at IETF but available on Centralnic
gitlab server)
HTH,
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailma
there is no registrar
object. It would look like a missing piece in the puzzle.
So having a generic organisation would be useful to code for many
cases, and do not emphasize resellers as being a more important
objects than others.
And +1 for the IANA registry on type
ays show me:
hashed
While I can understand the intent, I still believe it is not true to
EPP spirit and design.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
r a
> domain.
+1 for me for all the reasons Antoin, Scott and Alex have already
said.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e a
default initial registration period if not specified by the
client.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ence, even "reserved" domain names should display princing, if there is
one for them.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
me wording about the contact:street nodes,
especially if their number changes with the update done.
It would probably be superfluous but I believe in this case it is
better to over specify things instead of under-specify since this
contact:update issue is quite ol
the Registry Mapping extension, that
could be suited for this task.
I would even be very happy if VeriSign
could push forward to make this EPP extension a standard, to be used
by many registries.
--
Patrick Mevzek
___
regext mailing list
regext@
> at the domain object level and not the command level, so unless there
> are arguments to keep it at the command level the next version will
> move this to the object, , level.
I also believe that we talk about a class for a domain and not a class
for a command,
so it should be t
fees in any case. The extension is here
to be as specific as possible, this is cleatly not the good spot to try
reducing the bytes count.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
tead
of per domain would be a better choice than adding an attribute.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
with multiple domains and only one token are less
useful.
For implementation status, if you wish you can add the Net::DRI client
to the list.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
on: I would prefer that we stick to one, which may
appeal to some and not to others, instead of trying to accomodate too
many disparate or even opposite goals.
> If you have another proposal to address this use case, please share it.
My proposal is to keep things as is, with the
y, like technical ones
related to resolution
- for contacts being automatically purged by a registry after
some time of non-use
- etc.
Implementation status: you can add Net::DRI as a client if you like,
it implements all the draft.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
formation would
go against a lot of laws, especially now in Europe.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e 2 solutions involve schema changes so are more difficult
to put in place,
but I see them are more future-proof.
Sorry if I'm late to the game and I revisit already rehashed grounds.
Regards,
--
Patrick Mevzek
p...@dotandco.com
___
t I just wanted
to voice my concerns.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
not into some kind of structured format
like JSON.
Where on the opposite, inside RDAP we have the luxury of the JSON
structure.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ions showing that changes
like IDNs to a core protocol were not necessarily the best choice.
See https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/
(a very interesting read for history decisions)
--
Patrick Mevzek
p...@dotandco.com
__
clearly material to discuss inside this working group, so I
favor adoption of this document.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
or the work on Net::DRI, and we can certainly add
> Net::DRI to the Implementation Status section. Can you provide the
> following key values to add to the draft or you can also submit a pull
> request to the EPP-Allocation-Token-Specification GitHub project
> (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git)
> if you want to define it yourself?
Ok, I will follow on that separately, thanks.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
> Working group - are there any other comments or review of this document.
I am working on a review for this document. I hope to be able to send it
tomorrow.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
ht
ply for the website under
this domain.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e things (a cronjob could have been left running at the
old
provider for example)
* Similar cases if there is a transfer of the domain name... should the trust
relationship be reset to its beginnings since in some of these cases this also
has the consequence of chan
Y uses it for domains it manages.
===
comments related to both
===
I am more than a little fuzy about your "role" uses.
When you create an organization you specify a role,
and then when you create/update a domain to add an organization you again
specifcy a role.
Are they the same or different? Why do they need to be repeated?
This whole idea of "role" will need to be seriously improved in both documents.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
;org" extension not to be a good fit for that
endeavour, and I advise not modifying it in that direction.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ng.
However I think the rough consensus on the issue is clear, so we will
remain in a disagreement on this specific issue, but the draft would go along.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
object.
If it is the same value, then one of them is redundant and should be removed I
think.
I hope to understand this more in your later versions. Do not hesitate to add
more
text and examples.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
)
I am saying that the example is not clear, as it is using something
not even discussed in your document, without explanations.
But if it is clear for everyone else, then it is ok.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
reg
their database based on the "after"
messages
because in this specific case if they do it like that they will see the domain
existing, where it was deleted. So that message will have a specific handling
just
for it.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
I think we will agree to remain in disagreement on the subject itself,
as you put the protocol over the semantics and I do the opposite.
However putting more text and explanations as you suggest would certainly
help implementers to better understand things, so this will be welcome I am
sure.
-
2.2?
It seems to nicely explain things, so I am happy with it.
Thanks for your changes and patience.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
oing that road there are many other issues, small by
themselves but not negligible, that could be changed and enhanced in EPP.
So, in short, while technically the simplest/fastest case, this is unlikely to
happen.
--
Patrick Mevzek
___
regext maili
ot specify anything in its domain:info command)
HTH,
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
On Sat, Jan 6, 2018, at 20:01, Patrick Mevzek wrote:
> - I can not really imagine multiple versions of your extension in the
> wild at the same time (James/you speak about -01 vs -02), do you have a
> specific idea in mind?
And even in that case the client would surely at login spe
On Fri, Dec 22, 2017, at 07:03, Patrick Mevzek wrote:
> Hello authors,
>
> Please find below my review of your draft.
Please also have a look at
https://tools.ietf.org/id/draft-hildebrand-deth-00.txt
as it covers related goals (it is more generic than just NS/DS needs)
I do not know
nism for this.
So you are saying that the current EPP WhoisInfo extension designed to help
registrars
conduct transfers is not suited to do that?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
, if you are behind the sentence
you wrote, and if so if you can explain why it is mandatory.
Because I do not understand it.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
bably not be able to take part of the meeting for technical
reasons, but I hope that you would also take into account prior discussions
by email on this topic.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
se some help.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
On Mon, Jan 8, 2018, at 14:51, Stephane Bortzmeyer wrote:
> On Sat, Jan 06, 2018 at 08:01:02PM +0100,
> Patrick Mevzek wrote
> a message of 77 lines which said:
>
> > as soon as we add one RR through EPP, as James stated there is the
> > question about all others.
&g
hey use the extension to signal to the root to have one TLD being
a DNAME
to another?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
llow-up meeting to introduce and discuss this topic.
AFAIR this point has not been discussed on the mailing-list.
Could it start there maybe first?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
root-ish DNAMEs it might be more productive to consider how
> to invent a policy to allow a DNAME-only TLD if you're not a ccTLD.
But this won't be ontopic in this WG.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
) that permits Top-Level Domain (TLD)
managers to submit change requests , an Extensible Provisioning Protocol
(EPP) client and server system that communicates incoming
root zone change requests between the IFO and the RZM,
[..]
(IFO=IANA, RZM=Verisign as DNS root operator)
--
own-of-domain-check-dchk-lookup-service-as-of-3-december-2013/
.FR still runs it
(without any plan to stop it for what I am aware)
I am not aware of any other domain registries deployment.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
;E systems too: do they have notifications? If
so, where?
(because registrars may not poll on OT&E systems so it may make sense to
publish OT&E maintenances even on the production EPP server).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
I am not happy to have that set as a new standard/recommendation.
(and even less by the ~ character choice, but this is bikeshedding deriving
from what I think is the core problem: putting structure inside a non
structured element while all the surroundings being JSON is structured).
--
Patr
e or absence and
its value.
I would specifically think that details on its working regarding this other
sentence of the document will be needed:
Servers which make use of this element MUST use a element
with the value "standard" for all objects that are subject to the
standa
nformation about the transfer, then the server MAY include in the
section of the EPP response a element,"
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ence
I do not think it is good to overload it with other data in it formatted
in some way. XML is a format, if you need to carry some formatted things it
should be using XML elements/attributes, and not be serialized in some way in a
string element.
--
Patr
: global change of passwords because of a breach, registry ramp-up such
as a cut just before entering GA for example, EBERO switches maybe? etc.
- I would like a discussion on OT&E systems too: do they have notifications? If
so, where?
(because registrars may not poll on OT&
lack of explanations can cause major interoperability
problems, even more so because this attribute was added very late in the draft
lifecycle.
Maybe people in favor (I am not) of this attribute
should chime in and provide some useful text to add in the specification.
I do not think
So I can not support them, and this is why I say nothing, and while objecting
to them at various degrees, I have no strong enough feelings to be vocal about
them.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to change the schema at the last time clearly
shows to me that something is half-baked and should not be shipped as is.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ar to be my friend today ;-)
The same area of concerns were raised at least by Alexander Mayrhofer here:
https://mailarchive.ietf.org/arch/msg/regext/HgPkOGl0rVNwVZ9L8_37U1uS76o
and previously by myself here:
https://mailarchive.ietf.org/arch/msg/regext/LnvUUbjWzdez1MyHKDbPwkoywt0
and the threads fol
n is the simpler solution.
Also, like I said, noone complained on all of this since EPP started, so maybe
affected registrars and registries should speak up...
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
eys the meaning.
In short, if someone cares for this, in the client request and/or in server
reply, they should provide specific and detailed definition in the document.
If there is noone willing to define this element clearly in the specification,
I think it means that it need to be removed alto
l opinion has no weight.
As a shepherd for this document, my goal is to advance it in the IETF path now,
and discussions did already take place, so I will not restart them (other
participants are of course free to do it if they wish).
--
Patrick Mevzek
p...@dotandco.com
___
ponse. Client would just need to adapt, but it is the
case what ever happens and characters is used since there is no guarantee that
all IDs, even in the same repository, will be formatted with it.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ng (whatever token is best) inside the rdapConformance array to
signal to clients that object IDs are returned with some specific format, so
that they are aware of it.
And things remain compatible with current registries not using a specific
format and hence not adding this token.
--
sitting messages not being acknowledged by the
registrar. Some registries are then sending them by email for example after a
certain delay to be able to purge the queues.
I know others where there is no purge and you can find messages almost 10 years
old...
(the usefulness of such messages now is s
ot sending it creates more harm than benefits, even if the registrar
did not specify it at login, but clearly this is the core point of our
disagreement.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
(expedited?) work to conduct in this working group to
deliver solutions for proper RDAP layered access :-)
And Scott's drafts and experiments are probably very good starting points.
Let the festivities begin!
--
Patrick Mevzek
p...@dotandco.com
___
r
atever it chooses to use, before
applying any other kind of business rule, such as accepting or refusing the
command.
> IP addresses are anonymized.
Next time, for obfuscation, use guidance from RFC 3849.
--
Patrick Mevzek
p...@dotandco.com
__
it should do or not, and hence its possible
limitations.
I believe that you will need to clearly specify the intent and the goal you
want to reach with this, before the document could be reviewed and go forward.
--
Patrick Mevzek
___
regext mailin
and I am
not sure its current version correspond really to the working group consensus.
The above applies the same way for the two "organization" documents.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ng to
improve the end results of our work.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ices up to a separate draft.
I completely agree with this split.
The problem that was discussed after this draft has in fact nothing to do in
its core with poll messages, the issue, if there is one, is more global than
that. I will try to expose it in another email.
--
Pa
sulating one formatting
inside another, as the idea was already suggested (changing the pure textual
message by adding some formatting in it). Hence I would really not think that
using a CDATA block is a good idea.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
efore doing this step?
See also my email just before about the IETF 101 minutes for the same problem.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
while removing the X part, loosing it forever? Etc.
No great solution either here. This needs to be documented before any attempt
to solve
(and again I do not believe it will be possible to find a solution that fits
all cases, at best a guidance document clearly describing things, and
suggesting thin
favorable conclusion is not
really trying to discuss or come into agreement or consensus in my mind.
But again, I think we rehashed this point often enough now, so besides some
specific document to discuss, or other new views to exchange, it may be better
to let the thread die.
--
Patrick Me
hence HTTP/2) instead
of forcing retro-compatibilies, except if good reasons for that of course, this
is what I am curious about.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
lemented in the wild by registries and registrars to develop
> the appropriate interpretation of the RFC.
Which is absolutely not what I said.
So I will stop here, as I may be doing more harm than benefits to the WG by
continuing.
Regards,
--
ng that you need to use HTTP/1 with it and not the newer
HTTP/2.
And at least in the gTLD world, things could probably not implemented before
existing as an RFC. And some gTLDs are very small. This is not technical
related but may need to be taken into account if you wish for large adoption.
--
Pa
done should be done. This is the main point I will
try to address in a separate email since it is a generic issue, not
specifically related to this proposal.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
n pace.
> I guess it's the fact
> that roles are defined as properties of the organization and at the same
> time as properties of the link?
Yes, that is one troublesome point I raised months ago.
--
Patrick Mevzek
___
regext
ur concerns
> and it's up to others to decide whether the Draft can become a Proposed
> Standard
It is past LC like the chairs said, so the ship has sailed.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
of the latest iteration around these concepts was this draft:
https://tools.ietf.org/html/draft-gould-regext-dataset-01
HTH,
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
heir
support for this extension as it would help them for their various business
needs.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t as long as we're specifying this we might as well enable
> it to carry more detail than that.
I think this kind of explain many problems: it is not enough of a simple
signaling protocol, but too much of something more complicated with
authentication built in. I would think this is th
On Tue, Apr 24, 2018, at 21:02, Matthew Pounsett wrote:
> On 7 January 2018 at 18:28, Patrick Mevzek wrote:
>
> >
> >
> > On Fri, Dec 22, 2017, at 07:03, Patrick Mevzek wrote:
> > > Hello authors,
> > >
> > > Please find below my revie
itored by a
parental agent and acted on depending on local policy.
It specifically excludes CDS/CDNSKEY handling of course (section 5)
but it is a generic signalling protocol.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.
On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:
> Op 27 mei 2018, om 21:23 heeft Patrick Mevzek het
> volgende geschreven:
>
> > This is covered I think in ICANN world by section 1.4.2 of the whois
> > specification:
> >
> > "Additional data e
Antoin,
On Mon, May 28, 2018, at 22:40, Patrick Mevzek wrote:
>
>
> On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:
> > Op 27 mei 2018, om 21:23 heeft Patrick Mevzek het
> > volgende geschreven:
> >
> > > This is covered I think in ICANN
nsport having those
properties. Both "parts" should be able to evolve/be swapped independently as
long as the contract (the common set of properties agreed upon) remains valid.
As for EPP, each new transport should have a specification like it is done in
RFC 5734 for TLS.
--
1 - 100 of 248 matches
Mail list logo
