Re: [regext] draft-ietf-regext-epp-fees

[Thomas Corte]

Hello Roger,

On 2017-03-29 16:05, Roger D Carney wrote:

> Good Morning,
> 
> We had a very productive meeting at our IETF-98 Monday session.
> ...
> 
> I have started work on v3 (0.17) of the draft with these changes in mind.

I'm wondering about the status of this new draft version.
Is there an ETA for it?

Some of our registrars are waiting for an updated version of the fee
extension since they found the  functionality of
"urn:ietf:params:xml:ns:fee-0.11" unusable.
However, introducing support for "urn:ietf:params:xml:ns:fee-0.15" seems
pointless if a new version (with further changes to the  command)
is around the corner.

Best regards,

Thomas

-- 
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

[Roger D Carney]

Good Morning,



Thanks for the note Thomas. We are working on the final edits this week and 
hope to have a draft posted within the week.





Thanks

Roger





-Original Message-
From: Thomas Corte [mailto:thomas.co...@knipp.de]
Sent: Tuesday, April 18, 2017 3:25 AM
To: Roger D Carney ; regext@ietf.org
Cc: supp...@tango-rs.com
Subject: Re: [regext] draft-ietf-regext-epp-fees



Hello Roger,



On 2017-03-29 16:05, Roger D Carney wrote:



> Good Morning,

>

> We had a very productive meeting at our IETF-98 Monday session.

> ...

>

> I have started work on v3 (0.17) of the draft with these changes in mind.



I'm wondering about the status of this new draft version.

Is there an ETA for it?



Some of our registrars are waiting for an updated version of the fee extension 
since they found the  functionality of "urn:ietf:params:xml:ns:fee-0.11" 
unusable.

However, introducing support for "urn:ietf:params:xml:ns:fee-0.15" seems 
pointless if a new version (with further changes to the  command) is 
around the corner.



Best regards,



Thomas



--

TANGO REGISTRY SERVICES(r) 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] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Niels ten Oever]

Hi all,

I just found out that this draft standards is already being approved by
ICANN since February, which somehow seems a bit the wrong way around:

https://www.icann.org/en/system/files/correspondence/papac-to-kane-27feb17-en.pdf

I brought up on this list and in the past two sessions that this
document would really benefit from Privacy Considerations (RFC6973).

Not only because it is a good thing to do, but also because if we want
these practices to exist for some time they will need to abide by
privacy regulations (such as the upcoming GODR [0]).

All the best,

Niels

[0] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation


On 04/17/2017 02:18 PM, 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   : Verification Code Extension for the Extensible 
> Provisioning Protocol (EPP)
> Author  : James Gould
>   Filename: draft-ietf-regext-verificationcode-01.txt
>   Pages   : 35
>   Date: 2017-04-17
> 
> Abstract:
>This document describes an Extensible Provisioning Protocol (EPP)
>extension for including a verification code for marking the data for
>a transform command as being verified by a 3rd party, which is
>referred to as the Verification Service Provider (VSP).  The
>verification code is digitally signed by the VSP using XML Signature
>and is "base64" encoded.  The XML Signature includes the VSP signer
>certificate, so the server can verify that the verification code
>originated from the VSP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-regext-verificationcode-01
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-verificationcode-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-verificationcode-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint8D9F C567 BEE4 A431 56C4
 678B 08B5 A0F2 636D 68E9

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

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Hollenbeck, Scott]

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Niels ten Oever
> Sent: Tuesday, April 18, 2017 8:31 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-
> verificationcode-01.txt
>
> Hi all,
>
> I just found out that this draft standards is already being approved by
> ICANN since February, which somehow seems a bit the wrong way around:
>
> https://www.icann.org/en/system/files/correspondence/papac-to-kane-
> 27feb17-en.pdf
>
> I brought up on this list and in the past two sessions that this document
> would really benefit from Privacy Considerations (RFC6973).
>
> Not only because it is a good thing to do, but also because if we want
> these practices to exist for some time they will need to abide by privacy
> regulations (such as the upcoming GODR [0]).

Niels, if I remember correctly James Gould asked you at the Chicago meeting if 
you could help with proposed text to be added to the document, and I think you 
agreed. Have you had a chance to work with him to come up with that text?

Scott

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

[regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-03.txt

[Hollenbeck, Scott]

> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, April 18, 2017 8:34 AM
> To: i-d-annou...@ietf.org
> Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rdap-object-tag-
> 03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Registration Data Access Protocol (RDAP) Object
> Tagging
> Authors : Scott Hollenbeck
>   Andrew Lee Newton
>   Filename: draft-hollenbeck-regext-rdap-object-tag-03.txt
>   Pages   : 12
>   Date: 2017-04-18
>
> Abstract:
>The Registration Data Access Protocol (RDAP) includes a method that
>can be used to identify the authoritative server for processing
>domain name, IP address, and autonomous system number queries.  The
>method does not describe how to identify the authoritative server for
>processing other RDAP query types, such as entity queries.  This
>limitation exists because the identifiers associated with these query
>types are typically unstructured.  This document describes an
>operational practice that can be used to add structure to RDAP
>identifiers that makes it possible to identify the authoritative
>server for additional RDAP queries.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/

This version includes a description of the Verisign Labs implementation of the 
proposed tagging scheme.

With this update I would like to ask the chairs to ask the WG to consider 
adoption of this document. I would also like to ask anyone else who might have 
implemented the scheme to let me know so that I can add more information to the 
Implementation Status section.

Scott

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

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Gould, James]

Niels comment in Chicago was related to the reseller drafts.  Neils, if you 
have proposed text to add to draft-ietf-regext-verificationcode, please share 
it publically or privately.  

Thanks,
 
—
 
JG



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

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

VerisignInc.com  

On 4/18/17, 8:41 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Niels ten Oever
> Sent: Tuesday, April 18, 2017 8:31 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-
> verificationcode-01.txt
>
> Hi all,
>
> I just found out that this draft standards is already being approved by
> ICANN since February, which somehow seems a bit the wrong way around:
>
> https://www.icann.org/en/system/files/correspondence/papac-to-kane-
> 27feb17-en.pdf
>
> I brought up on this list and in the past two sessions that this document
> would really benefit from Privacy Considerations (RFC6973).
>
> Not only because it is a good thing to do, but also because if we want
> these practices to exist for some time they will need to abide by privacy
> regulations (such as the upcoming GODR [0]).

Niels, if I remember correctly James Gould asked you at the Chicago meeting 
if you could help with proposed text to be added to the document, and I think 
you agreed. Have you had a chance to work with him to come up with that text?

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

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Niels ten Oever]

On 04/18/2017 02:41 PM, Hollenbeck, Scott wrote:
>> -Original Message- From: regext
>> [mailto:regext-boun...@ietf.org] On Behalf Of Niels ten Oever Sent:
>> Tuesday, April 18, 2017 8:31 AM To: regext@ietf.org Subject:
>> [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext- 
>> verificationcode-01.txt
>> 
>> Hi all,
>> 
>> I just found out that this draft standards is already being
>> approved by ICANN since February, which somehow seems a bit the
>> wrong way around:
>> 
>> https://www.icann.org/en/system/files/correspondence/papac-to-kane-
>>
>> 
27feb17-en.pdf
>> 
>> I brought up on this list and in the past two sessions that this
>> document would really benefit from Privacy Considerations
>> (RFC6973).
>> 
>> Not only because it is a good thing to do, but also because if we
>> want these practices to exist for some time they will need to abide
>> by privacy regulations (such as the upcoming GODR [0]).
> 
> Niels, if I remember correctly James Gould asked you at the Chicago
> meeting if you could help with proposed text to be added to the
> document, and I think you agreed. Have you had a chance to work with
> him to come up with that text?
> 
> Scott

I did not work on this with James, but I remain happy to help.

Best,

Niels


> 

-- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint8D9F C567 BEE4 A431 56C4
 678B 08B5 A0F2 636D 68E9

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

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Niels ten Oever]

Hi James,

You're right. In Berlin I mentioned it in relation to the verification
code draft (and brought up the statement about it [0]), but similar
there are definitely also considerations for the resellers draft.

Question is: should we create privacy considerations per draft, or would
it make more sense to make a draft with Privacy Considerations for EPP
(similar to RFC7819 did for DHCP).

Best,

Niels



[0]
https://www.article19.org/resources.php/resource/38577/en/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules

On 04/18/2017 03:00 PM, Gould, James wrote:
> Niels comment in Chicago was related to the reseller drafts.  Neils,
> if you have proposed text to add to
> draft-ietf-regext-verificationcode, please share it publically or
> privately.
> 
> Thanks,
> 
> —
> 
> JG
> 
> 
> 
> James Gould Distinguished Engineer jgo...@verisign.com
> 
> 703-948-3271 12061 Bluemont Way Reston, VA 20190
> 
> VerisignInc.com 
> 
> On 4/18/17, 8:41 AM, "regext on behalf of Hollenbeck, Scott"
> 
> wrote:
> 
>> -Original Message- From: regext
>> [mailto:regext-boun...@ietf.org] On Behalf Of Niels ten Oever Sent:
>> Tuesday, April 18, 2017 8:31 AM To: regext@ietf.org Subject:
>> [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext- 
>> verificationcode-01.txt
>> 
>> Hi all,
>> 
>> I just found out that this draft standards is already being
>> approved by ICANN since February, which somehow seems a bit the
>> wrong way around:
>> 
>> https://www.icann.org/en/system/files/correspondence/papac-to-kane-
>
>> 
> 27feb17-en.pdf
>> 
>> I brought up on this list and in the past two sessions that this
>> document would really benefit from Privacy Considerations
>> (RFC6973).
>> 
>> Not only because it is a good thing to do, but also because if we
>> want these practices to exist for some time they will need to abide
>> by privacy regulations (such as the upcoming GODR [0]).
> 
> Niels, if I remember correctly James Gould asked you at the Chicago
> meeting if you could help with proposed text to be added to the
> document, and I think you agreed. Have you had a chance to work with
> him to come up with that text?
> 
> Scott
> 
> ___ regext mailing list 
> regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
> 
> 

-- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint8D9F C567 BEE4 A431 56C4
 678B 08B5 A0F2 636D 68E9

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

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Hollenbeck, Scott]

smime.p7m
Description: S/MIME encrypted message
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

[Hollenbeck, Scott]

(Sorry, resending due to a corporate mailer encryption setting user error on my 
part).

> -Original Message-
> From: Niels ten Oever [mailto:li...@digitaldissidents.org]
> Sent: Tuesday, April 18, 2017 9:29 AM
> To: Gould, James ; Hollenbeck, Scott
> ; 'regext@ietf.org' 
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-
> verificationcode-01.txt
>
> Hi James,
>
> You're right. In Berlin I mentioned it in relation to the verification
> code draft (and brought up the statement about it [0]), but similar there
> are definitely also considerations for the resellers draft.

Could you elaborate on that, please? The reseller (soon to be generic 
organization, I believe) draft(s) describe a means of exchanging information 
to identify an organization. Which bits of information do you see having human 
rights considerations?

> Question is: should we create privacy considerations per draft, or would
> it make more sense to make a draft with Privacy Considerations for EPP
> (similar to RFC7819 did for DHCP).

I don't know that I can answer that question without a better explanation of 
the kinds of things to be considered. I *can* see issues associated with 
personal privacy and the publication of contact information in WHOIS and/or 
RDAP (which points towards considerations for a document like RFC 5733), but 
where do you see considerations for a document like RFC 5732 in which there is 
no exchange of information associated with humans?

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