[regext] Minutes for wg meeting at IETF 96 Berlin

[Ulrich Wisser]

Hi all!

It seems I didn't send the minutes yet. Please find them below.
I hope I got all the names right. Please mail me any correction.

/Ulrich


-- 
Ulrich Wisser
ulr...@wisser.se
REGEXT WG meeting at IETF 96 Berlin 20th July 2016 15:50-17:20

WG chair Jim Galvin opens meeting  (Co-Chair Antoin Verschuren remote)

Signed-Mark has become RFC

draft-ietf-eppext-keyrelay
  Jim Galvin -  still in waiting for IPR specifics
  Rik Ribbers - asks Verisign to make an IPR statement accordance to BCP79

draft-ietf-regext-launchphase
   Jim Galvin - tight coupling with tmch-func-spec, has to wait for 
tmch-func-spec
   Sean Turner (via Jabber) downref is possible
   Jim Galvin - tmch-func-spec is needed for implementation, so no downref 
possible

draft-ietf-regext-epp-rdap-status-mapping
   Ulrich Wisser agreed to be the document shepherd

draft-ietf-regext-reseller / draft-ietf-regext-reseller-ext
   Jim Galvin - not much discussion on mailinglist
   Lingh - requests more reviews, outstanding issues fixed, draft updated
   Alex Mayrhofer - volunteers to review,
   Francisco Lozano - Reseller will be optional
   Jody Kolker - To much information is required if only name is shown in whois
   Jim Galvin - This needs to be discussedc on list
   James Gould (via Meetecho) - Information will be needed for future 
requirements
   Alex Mayrhofer - Extensions is not needed in operation, registry has no 
connection to reseller
 Reduce it to absolute minimum, only name
   James Gould - Wants the extensions to be open to a larger requirement
   Antoin Verschuren (via Jabber) -
   Go Daddy - Send name with create and be done???
   Jim Galvin - take discussion to the list

draft-brown-epp-fees
   Alex Mayrhofer - Discussion on list concludes to move the document back to a 
previous version
   Jim Galvin - we are waiting on Gavin Brown to submit a new version and 
restart the discussion

draft-ietf-regext-bundling-registration
   Jiankang Yao - Presents the extension
   Discussion in the room with many clarifying questions
   No consent on the specific bundling solutions
   Jim Galvin - further discussion needed

draft-ietf-regext-tmch-func-spec
   Gustavo Lozano (via Meetecho) - Outstanding comments fixed, thinks draft is 
ready to be published
   Jody Kolker - where does 48 hour window policy come from
   Gustavo Lozano - timeline has been discussed
   Jody Kolker - get rid of timeline all together
   Scott Hollenbeck - IETF does not write ICANN policy, let's try to find 
reconciliation
   Jim Galvin - Ping to Patrik XXX to provide feedback

draft-lozano-regext-epp-transf-contact-inf
draft-lozano-regext-rdap-transf-contact-inf
   Gustavo Lozano - Presents the extensions
   Discussion in room, draft needs more discussions on list

draft-carney-regext-validate
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-domainconnect
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-unavailable-domains
   Jody Kolker - presents the extension

draft-carney-regext-domain-fees
   Jody Kolker - presents the extension
   Please check with draft-brown-epp-fees

Jim Galvin asks for reviews on these drafts

Alex Mayrhofer please WG we have a lot of documents, very few reviews

Meeting closed by Jim Galvin
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Minutes for wg meeting at IETF 96 Berlin

[Ulrich Wisser]

I'll put that in the minutes.
/Ulrich

Hollenbeck, Scott  schrieb am Di., 26. Juli 2016
um 13:26 Uhr:

> Ulrich, one addition. In the Jabber room I did note that Verisign’s IPR
> declaration fully conforms to the guidance provided in BCP 79.
>
>
>
> Scott
>
>
>
> *From:* regext [mailto:regext-boun...@ietf.org] *On Behalf Of *Ulrich
> Wisser
> *Sent:* Tuesday, July 26, 2016 7:20 AM
> *To:* regext@ietf.org
> *Subject:* [regext] Minutes for wg meeting at IETF 96 Berlin
>
>
>
> Hi all!
>
>
>
> It seems I didn't send the minutes yet. Please find them below.
>
> I hope I got all the names right. Please mail me any correction.
>
>
>
> /Ulrich
>
>
>
>
>
> --
>
> Ulrich Wisser
>
> ulr...@wisser.se
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] draft-ietf-eppext-keyrelay

[Ulrich Wisser]

Hi all,

BCP 79 only requires the IPR declaration and some information on the
licensing policy.
No concrete license fees or policy is required. In it's IPR Verisign has
agreed to apply one of the following options

   - a) No License Required for Implementers
   - b) Royalty-Free, Reasonable and Non-Discriminatory License to All
   Implementers
   - c) Reasonable and Non-Discriminatory License to All Implementers with
   Possible Royalty/Fee

So maybe the WG can decide if that is enough information. I believe if we
indicate that the WG is
content with the information provided by Verisign, the IESG will forward
the document.

/Ulrich
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Minutes again

[Ulrich Wisser]

Here are the "new" minutes. Please check if your comments were fixed.

/Ulrich


-- 
Ulrich Wisser
ulr...@wisser.se
REGEXT WG meeting at IETF 96 Berlin 20th July 2016 15:50-17:20

WG chair Jim Galvin opens meeting  (Co-Chair Antoin Verschuren remote)

Signed-Mark has become RFC

draft-ietf-eppext-keyrelay
  Jim Galvin -  still in waiting for IPR specifics
  Rik Ribbers - asks Verisign to make an IPR statement accordance to BCP79
  ScottHollenbeck (via jabber) - Verisign statement is in accordance with BCP79

draft-ietf-regext-launchphase
   Jim Galvin - tight coupling with tmch-func-spec, has to wait for 
tmch-func-spec
   Sean Turner (via Jabber) downref is possible
   Jim Galvin - tmch-func-spec is needed for implementation, so no downref 
possible

draft-ietf-regext-epp-rdap-status-mapping
   Ulrich Wisser agreed to be the document shepherd

draft-ietf-regext-reseller / draft-ietf-regext-reseller-ext
   Jim Galvin - not much discussion on mailinglist
   Lingh - requests more reviews, outstanding issues fixed, draft updated
   Alex Mayrhofer - volunteers to review,
   Francisco Lozano - Reseller will be optional
   Jody Kolker - To much information is required if only name is shown in whois
   Jim Galvin - This needs to be discussedc on list
   James Gould (via Meetecho) - Information will be needed for future 
requirements
   Alex Mayrhofer - Extensions is not needed in operation, registry has no 
connection to reseller
 Reduce it to absolute minimum, only name
   James Gould - Wants the extensions to be open to a larger requirement
   Antoin Verschuren (via Jabber) -
   Go Daddy - Send name with create and be done???
   Jim Galvin - take discussion to the list

draft-brown-epp-fees
   Alex Mayrhofer - Discussion on list concludes to move the document back to a 
previous version
   Jim Galvin - we are waiting on Gavin Brown to submit a new version and 
restart the discussion

draft-ietf-regext-bundling-registration
   Jiankang Yao - Presents the extension
   Discussion in the room with many clarifying questions
   No consent on the specific bundling solutions
   Jim Galvin - further discussion needed

draft-ietf-regext-tmch-func-spec
   Gustavo Lozano (via Meetecho) - Outstanding comments fixed, thinks draft is 
ready to be published
   Jody Kolker - where does 48 hour window policy come from
   Gustavo Lozano - timeline has been discussed
   Jody Kolker - get rid of timeline all together
   Scott Hollenbeck - IETF does not write ICANN policy, let's try to find 
reconciliation
   Jim Galvin - Ping to Patrik XXX to provide feedback

draft-lozano-regext-epp-transf-contact-inf
draft-lozano-regext-rdap-transf-contact-inf
   Gustavo Lozano - Presents the extensions
   Discussion in room, draft needs more discussions on list

draft-carney-regext-validate
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-domainconnect
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-unavailable-domains
   Jody Kolker - presents the extension

draft-carney-regext-domain-fees
   Jody Kolker - presents the extension
   Patrick Mevzek - Please cross check with another extension done by Gavin 
Brown
   (detailed on mailinglist after the meeting to draft-brown-domain-pricing,
   not submitted at IETF but available on Centralnic gitlab server)

Jim Galvin asks for reviews on these drafts

Alex Mayrhofer please WG we have a lot of documents, very few reviews

Meeting closed by Jim Galvin
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Minutes

[Ulrich Wisser]

Hi there!

Here comes the latest version of the minutes.
Jim / Antoin would you load them up to the datatracker?

/Ulrich

-- 
Ulrich Wisser
ulr...@wisser.se
REGEXT WG meeting at IETF 96 Berlin 20th July 2016 15:50-17:20

WG chair Jim Galvin opens meeting  (Co-Chair Antoin Verschuren remote)

Signed-Mark has become RFC

draft-ietf-eppext-keyrelay
  Jim Galvin -  still in waiting for IPR specifics
  Rik Ribbers - asks Verisign to make an IPR statement accordance to BCP79
  ScottHollenbeck (via jabber) - Verisign statement is in accordance with BCP79

draft-ietf-regext-launchphase
   Jim Galvin - tight coupling with tmch-func-spec, has to wait for 
tmch-func-spec
   Sean Turner (via Jabber) downref is possible
   Jim Galvin - tmch-func-spec is needed for implementation, so no downref 
possible

draft-ietf-regext-epp-rdap-status-mapping
   Ulrich Wisser agreed to be the document shepherd

draft-ietf-regext-reseller / draft-ietf-regext-reseller-ext
   Jim Galvin - not much discussion on mailinglist
   Lingh - requests more reviews, outstanding issues fixed, draft updated
   Alex Mayrhofer - volunteers to review,
   Francisco Lozano - Reseller will be optional
   Jody Kolker - To much information is required if only name is shown in whois
   Jim Galvin - This needs to be discussedc on list
   James Gould (via Meetecho) - Information will be needed for future 
requirements
   Alex Mayrhofer - Extensions is not needed in operation, registry has no 
connection to reseller
 Reduce it to absolute minimum, only name
   James Gould - Wants the extensions to be open to a larger requirement
   Antoin Verschuren (via Jabber) -
   Go Daddy - Send name with create and be done???
   Jim Galvin - take discussion to the list

draft-brown-epp-fees
   Alex Mayrhofer - Discussion on list concludes to move the document back to a 
previous version
   Jim Galvin - we are waiting on Gavin Brown to submit a new version and 
restart the discussion

draft-ietf-regext-bundling-registration
   Jiankang Yao - Presents the extension
   Discussion in the room with many clarifying questions
   Marc Blanchet - We should not have multiple bundling extensions on standard 
track.
   Merge the requirements of this one and cira (already on the 
charter)
   and Gould’s one (not published) and possible icann idn
   variants work into a standard track extension.
   Marc committed to talk to the group of authors to start that thread.
   No consent on the specific bundling solutions
   Jim Galvin - further discussion needed

draft-ietf-regext-tmch-func-spec
   Gustavo Lozano (via Meetecho) - Outstanding comments fixed, thinks draft is 
ready to be published
   Jody Kolker - where does 48 hour window policy come from
   Gustavo Lozano - timeline has been discussed
   Jody Kolker - get rid of timeline all together
   Scott Hollenbeck - IETF does not write ICANN policy, let's try to find 
reconciliation
   Jim Galvin - Ping to Patrik XXX to provide feedback

draft-lozano-regext-epp-transf-contact-inf
draft-lozano-regext-rdap-transf-contact-inf
   Gustavo Lozano - Presents the extensions
   Discussion in room, draft needs more discussions on list

draft-carney-regext-validate
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-domainconnect
   Jody Kolker - presents the extension
   Discussion in room and Jabber

draft-carney-regext-unavailable-domains
   Jody Kolker - presents the extension

draft-carney-regext-domain-fees
   Jody Kolker - presents the extension
   Patrick Mevzek - Please cross check with another extension done by Gavin 
Brown
   (detailed on mailinglist after the meeting to draft-brown-domain-pricing,
   not submitted at IETF but available on Centralnic gitlab server)

Jim Galvin asks for reviews on these drafts

Alex Mayrhofer please WG we have a lot of documents, very few reviews

Meeting closed by Jim Galvin
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Implementations of draft-ietf-regext-epp-rdap-status-mapping-01

[Ulrich Wisser]

Hi everybody!

To finish the document shepherd writeup I would need to include references
to implementations.
Somebody who already has done this?
Who plans on implementing?

Thanks in advance!

Ulrich

-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Implementations of draft-ietf-regext-epp-rdap-status-mapping-01

[Ulrich Wisser]

Thanks guys! I include you in the writeup.
/Ulrich

Rik Ribbers  schrieb am Do., 15. Sep. 2016 um
09:17 Uhr:

> Hello Ullrich,
>
>
>
> We will implement this (as part of the mandatory RDAP implementation for
> gTLDs)
>
>
>
> Gr,
>
> Rik
>
>
>
> *From:* regext [mailto:regext-boun...@ietf.org] *On Behalf Of *Ulrich
> Wisser
> *Sent:* dinsdag 13 september 2016 9:12
>
>
> *To:* regext@ietf.org
> *Subject:* [regext] Implementations of
> draft-ietf-regext-epp-rdap-status-mapping-01
>
>
>
> Hi everybody!
>
>
>
> To finish the document shepherd writeup I would need to include references
> to implementations.
>
> Somebody who already has done this?
>
> Who plans on implementing?
>
>
>
> Thanks in advance!
>
>
>
> Ulrich
>
>
>
> --
>
> Ulrich Wisser
>
> ulr...@wisser.se
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG I-Ds in the IANA EPP Extensions Registry

[Ulrich Wisser]

Why wouldn't it be sufficient for ICANN if the extensions were just
submitted to the registry (without going through the WG)?
We did this with the .SE extensions.

/Ulrich

Hollenbeck, Scott  schrieb am Do., 13. Okt. 2016
um 13:01 Uhr:

> *From:* regext [mailto:regext-boun...@ietf.org] *On Behalf Of *Gustavo
> Lozano
> *Sent:* Wednesday, October 12, 2016 6:39 PM
> *To:* regext@ietf.org
> *Subject:* [regext] WG I-Ds in the IANA EPP Extensions Registry
>
>
>
> Hello colleagues,
>
>
>
> The gTLD base registry agreement requires Registries to provide and update
> the relevant documentation of all the EPP Objects and Extensions supported
> to ICANN prior to deployment. Currently, in order to comply with this
> provision, Registries upload their documentation through a portal
> maintained by ICANN.
>
>
>
> The proposal for the new version of this portal is to periodically
> download the EPP extensions registry (
> http://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml)
> allowing the registry to select entries from the IANA Registry. In other
> words, the EPP extension must be registered in the IANA EPP Registry in
> order to comply with this contractual provision.
>
>
>
> Several Registries have implemented EPP extensions described in WG I-Ds
> that are not registered in the IANA EPP registry. Is it appropriate to
> register a *WG* I-D in the IANA EPP Registry or should the author wait
> until the I-D becomes an RFC? Should it be a requirement to register the
> EPP extension in the IANA EPP registry shortly after becoming a WG item?
>
>
>
> [SAH] I believe it is more appropriate for an extension that is being
> developed through the IETF process to be registered only after it has been
> approved for publication as an RFC. Internet-Drafts are not guaranteed to
> be published as RFCs, and the specifications they describe can change
> before they are ultimately approved for RFC publication.
>
>
>
> Scott
> _______
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-12: (with DISCUSS and COMMENT)

[Ulrich Wisser]

Hi!

Yesterday at the DNSOP meeting some IPR issues came up.
At that meeting the AD and IAB told us explicitly that we can not discuss
the IPR.
Today I had a short talk with Andrew Sullivan about the IPR and he confirmed
that we are not supposed to discuss the IPR. The IPR is only meant to
allow us to make an informed decision.
The IPR was filed long before we went to LC. It was mentioned on the list
and in f2f meetings. So we can believe that the wg participants knew about
the
IPR when they agreed that the document is ready for publication.

What more should the wg have done?

/Ulrich

Stephen Farrell  schrieb am Do., 10. Nov. 2016
um 20:17 Uhr:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-eppext-keyrelay-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/
>
>
>
> --
> DISCUSS:
> --
>
>
> (1) The IPR declaration says that license terms will be available
> "later." As things stand, I don't understand how the WG can have
> made an informed decision in that case. I looked at the archive
> and saw essentially no discussion, other than the announcement. I
> also looked at the application and it's not crystal clear to me at
> least that none of the claims are relevant. The shepherd write-up
> also doesn't help me, but of course there may have been discussion
> in a f2f meeting that is documented in minutes or something - I've
> not checked for such, or I may have missed out on some list
> traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not
> how can WG participants have rationally considered an IPR
> declaration if the licensing information will only arrive "later"
> after the document is approved to become an RFC?  (Note: If I am
> explicitly told that this was considered and participants were ok
> with the declaration even as-is, then I'll clear.)
>
>
> --
> COMMENT:
> --
>
>
> OLD COMMENTS and cleared-DISCUSS point below. (There's
> no need to read beyond here:-)
>
> (2) So I can see at least two ways in which this kind of thing can
> be done and you don't clearly say which this supports. Option (a)
> would be for the gaining DNS operator to provide new public keys
> to the losing operator for inclusion before a transfer so that
> continuity is maintained during the transfer. Option (b) would be
> where the KSK private material is not known by either
> operator, but e.g. by the registrant. In the case of option (b)
> the DNSKEY would be transferred from the losing to the gaining DNS
> operator. (And the arrow in Figure 1 would be in the other
> direction.) I think you need to be clear about which of these
> cases is actually being supported and about the overall sequence
> of events needed. (If you tell me that you really want to do
> whatever is in draft-koch, then that's fine but then this draft is
> probably premature and draft-koch would need to be a normative
> ref.)
>
> - I think I'm missing an overview of EPP here. The intro could
> maybe do with a short para, and/or a pointer to something general.
> (Ah, I get it in section 3 - the ref to 5730 might be better in
> the intro.)
>
> - general: I think it'd be better to talk about public key values
> and not "key material" as the latter is often used to describe
> secret/private values which aren't at issue here. (Or else
> I'm mis-reading stuff:-)
>
> - nit, p8: s/previously send/previously sent/
>
> - Section 6: I'm surprised that you don't recommend or even note
> that the gaining registrar/dns operator should be able to check
> that the DNSKEY value it sees in XML is or is not the same as one
> that is published in the DNS and verifiable there. Wouldn't that
> kind of cross check be useful?
>
>
> --
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Clarify on RFC 5731

[Ulrich Wisser]

Greetings from Seoul!

At one of the last Centr meetings we came up with a clarifying question
about the domain:info response.

Today many implementations use the domain:authInfo as a token for domain
transfer.
That makes domain:authInfo really sensitive. Basically it puts it in the
same class as passwords.
As we have all learned in the past, passwords should be saved as salted
hashes.
But this makes it impossible to return the domain:authInfo to the client.

RFC 5731 makes the auth:pw part in the domain:info report optional in the
xml schema. But the text in section 3.1.2 says

-  An OPTIONAL  element that contains authorization
  information associated with the domain object.  This element MUST
  only be returned if the querying client is the current sponsoring
  client or if the client supplied valid authorization information
  with the command.


Does this mean that it is ok to never return domain:authInfo?

/Ulrich


-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] jabber scribe and notes taker

[Ulrich Wisser]

I volunteer as notes taker.
/Ulrich

James Galvin  schrieb am Do., 17. Nov. 2016 um 15:03 Uhr:

> Do we have a volunteer to be a Jabber scribe and notes taker for our
> meeting tomorrow, Friday, 18 November, 9:30am Seoul local time?
>
> Thanks in advance!
>
> Jim
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

[Ulrich Wisser]

I believe the majority in the room in Seoul preferred to go forward.
(I certainly indicated my support of moving forward.)
Our area director seemed to have the same impression.
So if there isn't an outcry on the list, that's what we're doing, right?

/Ulrich

Jaap Akkerhuis  schrieb am Mo., 28. Nov. 2016 um
16:21 Uhr:

>  Miek Gieben writes:
>
>  >
>  >
>  > [ Quoting  in "Re: [regext]
> draft-ietf-eppext-keyr..." ]
>  > >Dear Working Group,
>  > >
>  > >TL;DR: the working group should move forward and disregard Verisign's
> IPR claim.
>  >
>  > +1 from me on this.
>  >
>
> Given all the argments I've seen on this list, going ahead seems to be
> the only way out of this stalemate.
>
> jaap
>
> _______
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] first reason not to do EPP and DNAME records?

[Ulrich Wisser]

I might be mistaken, but I believe that IANA sends root updates to Verisign
via EPP.
In that light, we would need an EPP extension before IANA can adopt a
policy to allow DNAME in the root.


Matthew Pounsett  schrieb am Mo., 15. Jan. 2018 um
20:10 Uhr:

> On 15 January 2018 at 13:09, John R Levine  wrote:
>
>> Already replied but see
>>> <https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c
>>> >
>>>
>>
>> This answer just confirms my main point.  Whether to put DNAMEs in the
>> root is primarily a policy question.  Even if you thought it was a good
>> idea (which I still don't, see next message) there is no point to inventing
>> an EPP extension unless and until there is a policy that lets them use it.
>>
>> If merely having the EPP feature was all it took, we'd have sunrise and
>> redemption periods in the root.
>>
>> Perhaps I missed this upthread somewhere, but before we start talking
> about EPP extensions for managing the root, shouldn't we talk about using
> EPP to manage the root?  Last I heard (May 2017, Spain) there was work
> underway for a custom API for TLD->IANA changes that does not involve EPP.
> I imagine shifting gears to replace that with an EPP interface would be a
> significant undertaking by this time.
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>


-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Interest in collaborating on an EPP over HTTP draft?

[Ulrich Wisser]

Hi!

In the discussion on http/1.1 or http/2, I would like to mention, that
registries have a special kind of customers, the snapback registrars. An
unfiltered http/2 would allow them to use a lot of resources on the
registry side. And these people really do try to get it all. That is not
really what we want. And I don't think these properties of http/2 are very
well understood currently.

/Ulrich

>
> --
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WGLC: revised charter

[Ulrich Wisser]

+1

Jody Kolker  schrieb am Fr., 29. Juni 2018 um
19:05 Uhr:

> +1
>
> Thanks,
> Jody Kolker
>
> -Original Message-
> From: regext  On Behalf Of Gould, James
> Sent: Friday, June 29, 2018 11:07 AM
> To: Kal Feher ; regext@ietf.org
> Subject: Re: [regext] WGLC: revised charter
>
> +1
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271 <(703)%20948-3271>
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/29/18, 12:06 PM, "regext on behalf of Kal Feher" <
> regext-boun...@ietf.org on behalf of i...@feherfamily.org> wrote:
>
> +support
>
>
> On 29/6/18 11:11 pm, James Galvin wrote:
> > Just a reminder that the last call closes today.
> >
> > Please do indicate your support for the publication of this charter..
> >
> > Thanks,
> >
> > Antoin and Jim
> > WG co-Chairs
> >
> >
> >
> >
> > On 22 Jun 2018, at 8:33, James Galvin wrote:
> >
> >> The co-chairs believe that the attached revised charter for this
> >> working group is ready to be submitted to the IESG for review and
> >> approval.
> >>
> >> Please indicate your support for the publication of this charter.
> >>
> >> If any working group members has any questions or concerns
> regarding
> >> this charter please respond on list by close of business
> everywhere,
> >> Friday, 29 June 2018.  If there are no objections the document will
> >> be submitted to the IESG.
> >>
> >> Thanks,
> >>
> >> Antoin and Jim
> >> WG Co-Chairs
> >
> > ___
> > regext mailing list
> > regext@ietf.org
> > https://www.ietf.org/mailman/listinfo/regext
>
> --
> Kal Feher
> Melbourne, Australia
>
> _______
> 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
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Ulrich Wisser]

Hi,

are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two categories.
- do never poll
- poll and ignore anyway

I know that we have registrars who validate, but those usually support all
our extensions.

Could anybody produce numbers on registrars who do all three?
  1. poll
  2. validate
  3. do not support all extensions

/Ulrich





Martin Casanova  schrieb am Mo., 16. Juli 2018
um 15:09 Uhr:

> Patrick
>
> To be clear the domain info response will be sent just without the DNSSec
> part. Therefore a not DNSSec interested registrar will just not see the
> DNSSec configuration but all the rest of the domain info resData. I don't
> see a problem with that.
>
> In our case a registrar currently needs to be accredited by us
> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
> configured and he will only be able to transfer a DNSSec domain to him if
> the configured DNSSec at login.
>
> In case he is DNSSec enabled but still logs in without this extension he
> will get a failure with error message similar to  “Not allowed to transfer
> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>
> So actually there is a way to know why it didn't work for him.
>
> As a matter of fact we will have to over think this rule now because with
> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
> (which does not need to be the registrar) . So a domain of a non DNSSec
> accredited registrar could end up with  DNSSec data. In case he is DNSSec
> accredited he might be interested to keep his DNSSec Data synchronized with
> the data at the registry originated by CDS. That is exactly our use case
> where we want to use the change poll extension.
>
> Martin
> 
> Von: regext [regext-boun...@ietf.org]" im Auftrag von "Patrick
> Mevzek [p...@dotandco.com]
> Gesendet: Montag, 16. Juli 2018 20:31
> An: regext@ietf.org
> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
> Action: draft-ietf-regext-change-poll-07.txt)
>
> On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> > I believe that the login
> > services defines what the server can return to the client, so if the
> > client does not support the DNSSEC extension it is completely reasonable
> > for the server not to return it.  If a client wants to see the DNSSEC
> > information returned they should include the URI in their login
> > services.
>
> James, please, again, take into account some real life examples that
> happen today:
>
> registries restrict the use of secDNS at login for only the registrars
> having passed
> a specific accreditation test (trying to login with it without prior
> registry vetting triggers an authentication error, so the registrar can
> only do its business if it removes this extension from list at login)
> thus, in your case (just removing the content), a registrar not wanting to
> do DNSSEC and not wanting to transfer
> to him a currently DNSSEC-enabled domain will have no way to know that.
>
> And saying to registrars: "then pass registry accreditation tests to be
> able to login with secDNS and see **others** domain names with secDNS data
> while you do not want to do any DNSSEC related stuff", is certainly not
> going to fly...
>
> As long as we take into account only some cases and not others we will
> never be
> able to deliver an extension used by multiple registries.
> Also, before anything happen I will be very interested by intention of
> support
> (which means deployment) from registries.
>
> Otherwise, like I said, this problem exists since EPP started so it is not
> new,
> and it seems the current status quo fits most of the player (due to the
> number of people
> having participated here), so we are maybe devoting resources to trying to
> design
> something perfect... that noone will then use :-(
>
> --
>   Patrick Mevzek
>
> _______
> 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
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Ulrich Wisser]

Hi Martin,

as was said in the wg session, you are a registrar to a registry. You
probably have a contract and in most cases, you have to go through some
sort of OTE.
So how would you get into a situation where you cannot validate data from
the registry? Of course you could choose to not support one of the
extensions and just ignore those messages. By all means, do that. And I
mean do that, ignore the message. From a registry perspective there is no
good way to handle this. None of the proposals leads to actual fixing of
the problem. It just helps lazy registrars to ignore the problem. That can
be achieved cheaper!

/Ulrich


Martin Casanova  schrieb am Mo., 16. Juli 2018
um 18:09 Uhr:

> Hello Ulrich
>
> I don't know the numbers but I think you are right that most registrars
> don't care too much yet.
> On the other hand there are some new extensions in the pipeline that use
> the poll mechanism. (change poll, balance etc.)
>
> Thats why I believe it will/should become more important in the future.
>
> The number of validating clients may be small but I don't believe that we
> can ignore them and send our poll message with extensions regardless of the
> configured login services.
> Even if some of the registrars don't implement according to the standards,
> I think at least the registries should do so and creating a poisoned
> message is therefore not an option for us.
>
> So the only alternative to deal with it is to not send the extension part
> and in some cases this means to not send a poll message at all.
>
> Therefore a client has no option of knowing that he is missing out on some
> information unless studying the manuals of the registry...
>
> I think that this is hindering the development of EPP Poll extensions for
> no good reason. Out of sight - out of mind...
>
> Martin
>
>
>
> --
> *Von:* Ulrich Wisser [ulr...@wisser.se]
> *Gesendet:* Montag, 16. Juli 2018 21:58
> *An:* Martin Casanova
> *Cc:* Patrick Mevzek; regext@ietf.org
>
> *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re:
> I-D Action: draft-ietf-regext-change-poll-07.txt)
> Hi,
>
> are we really sure this is a problem worth solving?
> At .se registrars (with very few exceptions) fall into two categories.
> - do never poll
> - poll and ignore anyway
>
> I know that we have registrars who validate, but those usually support all
> our extensions.
>
> Could anybody produce numbers on registrars who do all three?
>   1. poll
>   2. validate
>   3. do not support all extensions
>
> /Ulrich
>
>
>
>
>
> Martin Casanova  schrieb am Mo., 16. Juli 2018
> um 15:09 Uhr:
>
>> Patrick
>>
>> To be clear the domain info response will be sent just without the DNSSec
>> part. Therefore a not DNSSec interested registrar will just not see the
>> DNSSec configuration but all the rest of the domain info resData. I don't
>> see a problem with that.
>>
>> In our case a registrar currently needs to be accredited by us
>> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
>> configured and he will only be able to transfer a DNSSec domain to him if
>> the configured DNSSec at login.
>>
>> In case he is DNSSec enabled but still logs in without this extension he
>> will get a failure with error message similar to  “Not allowed to transfer
>> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>>
>> So actually there is a way to know why it didn't work for him.
>>
>> As a matter of fact we will have to over think this rule now because with
>> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
>> (which does not need to be the registrar) . So a domain of a non DNSSec
>> accredited registrar could end up with  DNSSec data. In case he is DNSSec
>> accredited he might be interested to keep his DNSSec Data synchronized with
>> the data at the registry originated by CDS. That is exactly our use case
>> where we want to use the change poll extension.
>>
>> Martin
>> 
>> Von: regext [regext-boun...@ietf.org]" im Auftrag von "Patrick
>> Mevzek [p...@dotandco.com]
>> Gesendet: Montag, 16. Juli 2018 20:31
>> An: regext@ietf.org
>> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re:
>> I-D Action: draft-ietf-regext-change-poll-07.txt)
>>
>> On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
>> > I believe that the login
>> > services defines what the server can return to the client, so if the
>> > client does not support the DNSSEC extension it is comp

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Ulrich Wisser]

Martin,

if I understand you right, the problem is ignorant registrars. And the
solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.

Clear communication with registrars and all internal departments sounds
more feasible.
We deploy these changes six months in advance in our OTE environment.
We check who tested and actively contact registrars that don't.
The only time we had to do a rollback was when the product owner thought
that would be unnecessary.

/Ulrich


Martin Casanova  schrieb am Di., 17. Juli 2018
um 05:10 Uhr:

> Hi Ulrich
>
>
> We do have contracts yes. However experience shows us that some registrars
> just don't have the necessary technical skills or means to react on any
> changes we ask them to implement. To pull a change through, long dead lines
> must be granted and even after that, only a part of them actually got
> active. Many registrars only react after we don’t support the outdated
> options anymore and then call our support to ask why it fails, even though
> they were reminded several times.
>
>
> In this cases customer relations will ask the technical team to make an
> exception for so and so registrar until he fixed his client which leads to
> more work having to configure opt out for single registrars. Also there is
> no standard way of triggering registry initiated messages in OTE yet.
>
>
> So knowing this we were looking for a more elegant way than going through
> this hassle for every new poll extension we plan to implement. (That's the
> situation where clients cannot validate data from the registry)
>
>
> To ask the registrars to ignore “unknown” extensions would be the same as
> asking them not to validate the poll responses at all or to at least skip
> poll messages for which validation fails due to unhandled name-spaces since
> this could occur any time a new poll extension is implemented.
>
>
> If the extended poll messages are sent regardless of the configured login
> services, would that not contradict the idea that only the intersecting set
> of extensions configured in greeting and login are activated for a session?
> That’s how I understood Scott Hollenbeck examples but I may be wrong.
>
>
> If there is a consent in the WG about these two last points I agree it is
> also an easy solution to just send the message and expect the clients to
> cope with it.
>
>
> Martin
>
> --
> *Von:* Ulrich Wisser [ulr...@wisser.se]
> *Gesendet:* Dienstag, 17. Juli 2018 02:27
>
> *An:* Martin Casanova
> *Cc:* Patrick Mevzek; regext@ietf.org
> *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re:
> I-D Action: draft-ietf-regext-change-poll-07.txt)
> Hi Martin,
>
> as was said in the wg session, you are a registrar to a registry. You
> probably have a contract and in most cases, you have to go through some
> sort of OTE.
> So how would you get into a situation where you cannot validate data from
> the registry? Of course you could choose to not support one of the
> extensions and just ignore those messages. By all means, do that. And I
> mean do that, ignore the message. From a registry perspective there is no
> good way to handle this. None of the proposals leads to actual fixing of
> the problem. It just helps lazy registrars to ignore the problem. That can
> be achieved cheaper!
>
> /Ulrich
>
>
> Martin Casanova  schrieb am Mo., 16. Juli 2018
> um 18:09 Uhr:
>
>> Hello Ulrich
>>
>> I don't know the numbers but I think you are right that most registrars
>> don't care too much yet.
>> On the other hand there are some new extensions in the pipeline that use
>> the poll mechanism. (change poll, balance etc.)
>>
>> Thats why I believe it will/should become more important in the future.
>>
>> The number of validating clients may be small but I don't believe that we
>> can ignore them and send our poll message with extensions regardless of the
>> configured login services.
>> Even if some of the registrars don't implement according to the
>> standards, I think at least the registries should do so and creating a
>> poisoned message is therefore not an option for us.
>>
>> So the only alternative to deal with it is to not send the extension part
>> and in some cases this means to not send a poll message at all.
>>
>> Therefore a client has no option of knowing that he is missing out on
>> some information unless studying the manuals of the registry...
>>
>> I think that this is hindering the development of EPP Poll extensions for
>> no good reason. Out of sight - out of mind...
>>
>> Martin
>

Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode

[Ulrich Wisser]

Hi,

I completely agree with Gurshabad assessment. But as others already pointed
out, it is an intended consequence of the extension.
In the context of domain registration, privacy cannot be expected. So my
question is rather, does this extension make the situation worse?

As you were asking for examples. China and Denmark require preregistration
of registrants. Denmark does even require preregistration of hosts. Denmark
has plans to only allow registrations with a Danish electronic id.

In my assessment, a registrant cannot have any expectation of privacy.
And therefore the extension does not worsen the situation for the
registrant.

/Ulrich


Vittorio Bertola  schrieb am Mi., 3.
Okt. 2018 um 17:05 Uhr:

> Il 3 ottobre 2018 alle 15.42 Niels ten Oever < li...@digitaldissidents.org>
> ha scritto:
>
>
> On Wed, Oct 03, 2018 at 01:14:10PM +, Gould, James wrote:
>
> The draft is intended for interoperability and is independent of the
> verification process.
>
>
> I am a bit confused with your reasoning that the verificationcode
> extension has is independent from the implementation of this extension,
> because the extension exists to enable implementation, right? Why else
> would it exist?
>
> The EPP extension takes no position on specific verification processes
> which are a "local matter" for the implementation.
>
> The EPP extension does enable it, so it does have a position on it.
>
> This exchange strikes me because of the discussion that we have been
> having on content tagging on HRPC (Nalini, Barry and I are still working on
> it).
>
> So my question is: is any protocol that supports additional points of
> content control at the national level favouring censorship, and thus
> inherently bad and contrary to human rights?
>
> Or even, if you prefer: is all censorship inherently bad? More
> specifically, if the national government or policy verification authority
> used the proposed EPP extension to block the registration of
> lets-kill-all-the-jews.cctld or child-pornography-for-everyone.cctld, is it
> censoring the Internet, or is it just doing its job on behalf of its
> citizens?
>
> And in that context, shouldn't the right to free expression of the user be
> balanced with the right to cultural and legal sovereignty of that country's
> citizens, which may end up establishing laws which legitimately make some
> content illegal in their country? (not to mention the rights of the people
> that may be harmed by the circulation of certain content)
>
> All in all, and with no offense for the reviewer's laudable efforts, the
> assessment in the review that any local point of control is bad because it
> could be used to harm someone's rights is IMHO too simplistic: it could
> also be used to defend someone else's rights.
>
> Regards,
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] RegistryLock draft (as promised)

[Ulrich Wisser]

Hi,

as promised at the Registry Lock side meeting and by Alex in the minutes
from the meeting,
here comes the link to my "secret" draft.

https://tools.ietf.org/html/draft-wisser-registrylock-00

Comments and improvements are of course welcome.

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

[regext] Update for .se extension

[Ulrich Wisser]

Designated experts, please consider the following update for the .se extension.

Kind Regards

/Ulrich




-BEGIN FORM-
Name of Extension:
.SE extension

Document Status:
Informational

Reference:
https://registrar.iis.se/96

Registrant Name and Email Address:
Internet Infrastructure Foundation 
hostmas...@internetstiftelsen.se

TLDs: .se .nu

IPR Disclosure: --

Status: Active

Notes: Update to reference (documents were moved)

-END FORM-

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

Re: [regext] Update for .se extension

[Ulrich Wisser]

Hi Scott,

“documents were moved” refers to the fact that the link to the XML spec at the 
IANA page doesn’t work any longer. The “manual” link in the notes points to an 
older version.
The new link points to a summary page where we publish the XML and the manual. 
The newest manual got an update because we detected some inconsistencies in the 
IDN definitions.

/Ulrich


From: "Hollenbeck, Scott" 
Date: Wednesday, 6 November 2019 at 17:55
To: Ulrich Wisser , "epp...@ietf.org" 

Subject: RE: Update for .se extension

Thanks, Ulrich. Is a summary of the changes available? I’m not sure I 
understand what “documents were moved” refers to.

Scott

From: regext  On Behalf Of Ulrich Wisser
Sent: Wednesday, November 6, 2019 9:22 AM
To: epp...@ietf.org
Subject: [EXTERNAL] [regext] Update for .se extension


Designated experts, please consider the following update for the .se extension.

Kind Regards

/Ulrich




-BEGIN FORM-
Name of Extension:
.SE extension

Document Status:
Informational

Reference:
https://registrar.iis.se/96

Registrant Name and Email Address:
Internet Infrastructure Foundation 
hostmas...@internetstiftelsen.se<mailto:hostmas...@internetstiftelsen.se>

TLDs: .se .nu

IPR Disclosure: --

Status: Active

Notes: Update to reference (documents were moved)

-END FORM-

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

Re: [regext] Implementations of draft-wisser-registrylock?

[Ulrich Wisser]

Hi,

I have made significant changes to the draft.
Many thanks to contributions by Michael Bauland and Bernhard
Reutner-Fischer.

Please find the draft at
https://datatracker.ietf.org/doc/draft-wisser-registrylock/

And please give it a review.

If your registry currently offers or will offer registry lock in the future
I would be interested to hear how this draft fits or doesn't fit your
business model.

Kind regards from Stockholm

/Ulrich





Am Fr., 27. März 2020 um 09:44 Uhr schrieb Bernhard Reutner-Fischer <
rep.dot@gmail.com>:

> On Wed, 25 Mar 2020 10:29:52 +0100
> Alexander Mayrhofer  wrote:
>
> > Hello everyone,
> >
> > Ulrich has published a new revision of his registry lock draft
> (draft-wisser-registrylock). We're currently in the
>
> In 4.2.5.  EPP  Command
> s/SEVER_UPDATE_PROHIBITED/serverUpdateProhibited/
>
> > I know that - as always - it's a chicken and egg problem, but I'd like
> to get a temperature of the room. And I know the document is an individual
> draft, but I suppose this working group is the most appropriate place to
> pose that question. I'm also more than happy to help in further development
> of the draft, if registries and registrars believe the document is useful!
> >
> > Feedback appreciated.
>
> The unlockUntil element was the missing bit.
>
> In 2.3.  Command Execution Restrictions
> There is
> ---8<---
> OPEN QUESTION: If a domain is under registry lock, can a subordinate
>host be updated?
> ---8<---
> That's a policy decision which might be further complicated by hostObj
> versus hostAttr. I would leave this as implementation defined.
>
>
> 4.1.2.  EPP  Command
> ---8<---
>   An OPTIONAL  element if the object currently can be
>   changed by the sponsoring client.  The field indicates the time
>   stamp when further changes will be impossible.
> ---8<---
> I'd clarify that as s/when/after which/ as in "the time stamp after
> which further changes".
>
> 4.2.1.  EPP  Command
> s/inteded/intended/g
>
> This allows for an initial domain:create with the lock unlockUntil set
> which is maybe useful for some. I hope registrars will get the data
> correct in the create frame right from the start but wouldn't reject
> seeing unlockUntil here. Can be handled by generic code and does no
> harm.
>
> 4.2.5.  EPP  Command
> s/unock/unlock/
>
> AFAICS this allows for the case of an existing normal domain being
> updated to add a registry lock where the lock is optionally unlockUntil
> which is handy.
>
> Just skimming over the -1 diff, did not read it thoroughly.
>
> Thanks for the update, Ulrich!
> cheers,
> Bernhard
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Implementations of draft-wisser-registrylock?

[Ulrich Wisser]

Hi Scott,

thank you, by now you have probably heard about Swedens unusual way to
handle the virus.
Just in case, here is a short reminder:
https://www.tiktok.com/@armandfuego/video/6817369611206479110

We actually do handle registry lock quite similar. We allow enabling it
through the extension, but we support only "outofband".
Our registrars have to login to our registrar portal to temporarily unlock
the domain or to remove registry lock all together.

For the in-band part of the extension to be used safely, we would first
need to come up with an OTP scheme for EPP.
Maybe that is something to work on for the future?

/Ulrich


Am Di., 7. Apr. 2020 um 18:57 Uhr schrieb Hollenbeck, Scott :

> *From:* regext  *On Behalf Of *Ulrich Wisser
> *Sent:* Tuesday, April 7, 2020 11:28 AM
> *To:* regext@ietf.org
> *Cc:* Alexander Mayrhofer ; Bernhard
> Reutner-Fischer ; michael.baul...@knipp.de
> *Subject:* [EXTERNAL] Re: [regext] Implementations of
> draft-wisser-registrylock?
>
>
>
> Hi,
>
>
>
> I have made significant changes to the draft.
>
> Many thanks to contributions by Michael Bauland and Bernhard
> Reutner-Fischer.
>
>
>
> Please find the draft at
> https://datatracker.ietf.org/doc/draft-wisser-registrylock/
>
>
>
> And please give it a review.
>
>
>
> If your registry currently offers or will offer registry lock in the
> future I would be interested to hear how this draft fits or doesn't fit
> your business model.
>
>
>
> I hope you’re doing well, Ulrich! The mechanism described in the draft
> isn’t one that Verisign plans to implement. We do offer a registry lock
> service, but it doesn’t use EPP to avoid situations in which a compromised
> registrar/sponsoring client could unlock a domain and make unauthorized
> changes. We support registrar-initiated management of the client* status
> values for registrar locking.
>
>
>
> Scott
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Implementations of draft-wisser-registrylock?

[Ulrich Wisser]

Hi Tim,

thanks for reading the document. I believe the dangling sentence is an
artifact of malformatting.
It tries actually to explain the out-of-band mechanics in more detail. Next
version will fix at
least the formatting.

As I already wrote in my reply to Scott, for the in-band to be used safely
we would need to
introduce an OTP scheme to EPP.

/Ulrich

Am Di., 7. Apr. 2020 um 19:07 Uhr schrieb Tim Wicinski :

>
> As an end-user i've always liked the out-of-band registrar-initiated
> management of the client status.
>
> I can see a registrar offering both in-band and out-of-band to their
> clients.
>
> Also, there appear to be some dangling sentences in section 2.
>
> tim
>
>
>
> On Tue, Apr 7, 2020 at 12:57 PM Hollenbeck, Scott  40verisign@dmarc.ietf.org> wrote:
>
>> *From:* regext  *On Behalf Of *Ulrich Wisser
>> *Sent:* Tuesday, April 7, 2020 11:28 AM
>> *To:* reg...@ietf..org 
>> *Cc:* Alexander Mayrhofer ; Bernhard
>> Reutner-Fischer ; michael.baul...@knipp.de
>> *Subject:* [EXTERNAL] Re: [regext] Implementations of
>> draft-wisser-registrylock?
>>
>>
>>
>> Hi,
>>
>>
>>
>> I have made significant changes to the draft.
>>
>> Many thanks to contributions by Michael Bauland and Bernhard
>> Reutner-Fischer.
>>
>>
>>
>> Please find the draft at
>> https://datatracker.ietf.org/doc/draft-wisser-registrylock/
>>
>>
>>
>> And please give it a review.
>>
>>
>>
>> If your registry currently offers or will offer registry lock in the
>> future I would be interested to hear how this draft fits or doesn't fit
>> your business model.
>>
>>
>>
>> I hope you’re doing well, Ulrich! The mechanism described in the draft
>> isn’t one that Verisign plans to implement. We do offer a registry lock
>> service, but it doesn’t use EPP to avoid situations in which a compromised
>> registrar/sponsoring client could unlock a domain and make unauthorized
>> changes. We support registrar-initiated management of the client* status
>> values for registrar locking.
>>
>>
>>
>> Scott
>> ___
>> 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