Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

[Alexander Mayrhofer]

Hello all,

I'm with Antoine - i think a generic "organization" object that can fulfill 
"roles" with regards to an "object" would be better than a object definition 
that's only useful for one single reseller use case. Even more complicated 
"chains" of resellers [rolling eyes] could be implemented by defining a role of 
 "is-reseller-of" and allowing that an organization object links to another 
organization using that role.

specifically (as someone said in Seoul), i'm puzzled by the fact that by adding 
a specific "reseller" object, we treat entities which typically have no 
contractual relation whatsoever with the registry as first-class objects, while 
we treat registrars (which are typically required to have such a relation) as 
an opaque non-existant object class.

Of course, the downside of defining a generic "organization" object is  that 
flexibility also creates complexity, and the option defined above would 
essentially allow creating almost infinitely complex networks of organizations. 
I'm not convinced i want that - however, my understanding for the requirement 
to drill down the chain of resellers several levels is limited anyways. But 
we're venturing too far into policy here.

best,
Alex

Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Antoin Verschuren
Gesendet: Freitag, 3. März 2017 18:08
An: Gould, James
Cc: Hollenbeck, Scott; regext@ietf.org
Betreff: Re: [regext] Working group action required on 
draft-ietf-regext-reseller-ext-01.txt [x_phishing]

Hi James,

I understand your distinction between registrar and reseller, and I agree.
Registrars are provisioned differently, and have a formal role to provisioning 
objects and contracts, just as registrants do.
I didn't suggest to have registrars/registrants be transformed into generic 
organizations objects just yet if that was what you were thinking I meant.
It's other future roles that I see similar to resellers why I would want a 
generic organizational object to be used for resellers.
If the name "generic organization" confuses you, we might also call it 
"additional registration liaisons" or whatever is appropriate, but it's more 
than just resellers.

So in fact we would have 3 "objects" for entities/organizations:
1. Registrants (mandatory in any registration contract, even in a situation 
without registrars or resellers, yes, direct registrations still exist at some 
registries!)
2. Registrars (if present, usually authoritative for the provisioning data, and 
often also for billing information in the ICANN model at least)
3. All other organizations not formally defined by or mandatory in registration 
contracts.

The pragmatic problem being considered now is indeed making non contractual 
resellers visible, but I expect other organizations -not resellers- on the 
horizon with the same wish to be tagged to provisioning objects as well. They 
might need to be visible as well, or even have special permissions, and they 
might have multiple roles.
Roles I expect include dns-operators, auditors, expanded RDAP access 
credentials, abuse desks, law enforcement, privacy agents, data processors etc..
I wouldn't want to define a new object every time I wanted to innovate service 
to customers. I just want to give the object an additional role in relation to 
a provisioning object, so they can use the new service belonging with that role.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392




Op 3 mrt. 2017, om 16:12 heeft Gould, James 
mailto:jgo...@verisign.com>> het volgende geschreven:


I believe that "Option 1: A dedicated reseller object" is the best route to go. 
 I get the idea of creating a generic organization, but you need to consider 
the problem being considered and the difference of a registrar from a reseller.

1.  A registrar (direct customer) has a direct relationship with the 
registry and is provisioned outside of EPP or any B2B protocol.  A registrar 
organization would only support an info unless you enable a registrar to update 
their own record via EPP, which seems like a real stretch use case.
2.  A registrar is automatically attached to the provisioned objects (e.g., 
domain, host, and contact) in the registry based on the create and transfer 
commands.  There is need for tagging a provisioning object with a direct 
customer organization.

The problem that is being considered is making the resellers visible at the 
registry level to support tagging of provisioning objects for display in RDDS, 
for applying registrar controlled reseller policy (security, financial, etc.) 
at the registry level, and providing registry provided reports and 
visualizations split out by reseller.

Is there another problem that needs to be solved by elevating the reseller 
object up to the more generic organization?


-

JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

From: regext mailto:re

Re: [regext] draft-ietf-regext-epp-fees-02 : autoRenewPeriod and delete response

[Thomas Corte]

Hello Matthieu,

On 17/03/2017 18:19, Matthieu Jacob wrote:

> Hello,
> 
> I have a question about the delete command and precisely about the
> response when you delete a domain which is in autoRenewPeriod and the
> registrar has fee extension selected during the login, do we need to
> give the amount refund of the autorenew into the delete response?

Since the purpose of the extension is to tell registrars the financial
impact of a command, the delete response should indeed list all credits
(which includes applicable auto-renew credits, but also other potential
credits due to the domain being in its add/renew/transfer grace period)
via the fee extension.

We implemented this for the fee-0.11 version. fee-0.15 additionally lists
"delete" as a viable command to be passed to the  command, so
I believe it's now also necessary to determine such credits when the
deletion fees are merely checked for a specific domain name, i.e. to
return the credits that would be granted if the domain was deleted at the
time the  is received.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

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

[regext] draft-ietf-regext-epp-fees-02.txt: should the command name really be optional in ?

[Thomas Corte]

Hello,

On 09/03/2017 00:11, internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Registration Protocols Extensions of the 
> IETF.
> 
> Title   : Registry Fee Extension for the Extensible 
> Provisioning Protocol (EPP)
> Authors : Roger Carney
>   Gavin Brown
>   Jothan Frakes
>   Filename: draft-ietf-regext-epp-fees-02.txt
>   Pages   : 34
>   Date: 2017-03-08
> ...

Thanks for this updated fee extension draft.
While preparing its implementation, I noticed the following which may be
an error in the spec.

The draft's text suggests that the "name" attribute for the 
element in a  is mandatory, but this is not reflected in the
XSD (the attribute is left optional in the "commandType" complex type
declaration).

Unless the intention was to offer a "wildcard", enabling a client to
check all supported command without listing them, this attribute should
probably be marked as required.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

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

[regext] draft-ietf-regext-epp-fees-02.txt: may fees/credits be specified in a ?

[Thomas Corte]

Hello,

another oddity I noticed in draft-ietf-regext-epp-fees-02.txt:

Since "objectCheckType" (for check commands) and "objectCDType" (for
check responses) now practically contain the same elements (and both
reference "commandType"), it is possible for a registrar to specify fees
and credits along with all checked commands. The draft's text makes no
mention of this possibility, so I assume that this is simply not
supported and should either be ignored or cause an error response.

Alternatively, it may be intended that this shall serve as an extended
check whether the specified "assumed" fees and credits are correct for a
given domain name/command/phase/period combination. This should be clarified.

Generally, I'd prefer a schema which more rigidly defines correct
commands and responses, even if this means that certain XSD type
definitions cannot easily be reused for defining requests and responses.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

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

Re: [regext] draft-ietf-regext-epp-fees-02 : autoRenewPeriod and delete response

[Gould, James]

Inclusion of grace period credits is timed based (logic executed at the time of 
the delete) and is much more involved than returning the applicable prices.  
The extension of the availability check command in 
draft-ietf-regext-epp-fees-02 is already far beyond what is reasonable for an 
extension to check, so we should look to separate this into an extension to 
info in the form of a fee info command.  The RGP extension already includes 
information associated with the applicable grace periods, so inclusion of the 
actual credit values may not be necessary.   
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com  

On 3/20/17, 12:50 PM, "regext on behalf of Thomas Corte" 
 wrote:

Hello Matthieu,

On 17/03/2017 18:19, Matthieu Jacob wrote:

> Hello,
> 
> I have a question about the delete command and precisely about the
> response when you delete a domain which is in autoRenewPeriod and the
> registrar has fee extension selected during the login, do we need to
> give the amount refund of the autorenew into the delete response?

Since the purpose of the extension is to tell registrars the financial
impact of a command, the delete response should indeed list all credits
(which includes applicable auto-renew credits, but also other potential
credits due to the domain being in its add/renew/transfer grace period)
via the fee extension.

We implemented this for the fee-0.11 version. fee-0.15 additionally lists
"delete" as a viable command to be passed to the  command, so
I believe it's now also necessary to determine such credits when the
deletion fees are merely checked for a specific domain name, i.e. to
return the credits that would be granted if the domain was deleted at the
time the  is received.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
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