Re: [regext] list of documents to consider for working group adoption

[James Galvin]

Thanks to Scott, James, and Tobias.  The updated document list is 
included below.



On 7 Dec 2018, at 9:38, James Galvin wrote:

Included below is the list of potential documents and topics this 
working group could adopt.  The first step in moving forward is to 
make sure we have a complete list.  We are asking folks to review this 
list and make sure we have not missed anything.  We are allowing one 
week for this review, until Friday 14 December 2018.  During this time 
please do ask questions about documents or topics.


The next step will be for the working group members to indicate their 
top 5 choices of documents to move forward.  Recall that 5 is the 
maximum number of milestones suggested for us to have open at a time.  
If there is discussion to be had about this number please start a new 
email thread and we will see where it goes.


We will do this with a Doodle poll.  Hopefully you are familiar with 
this.  We will setup each document as a choice and you’ll be asked 
to select up to 5 documents.  In Doodle, you can select Yes, No, or 
IfNeedBe.  You can use the IfNeedBe option to indicate documents that 
you support but not as your top 5.  We will open this Doodle poll 
before the Christmas holiday and leave it open through Friday, 11 
January.  That should be plenty of time to get past holiday and 
vacation time that many folks will have during this time.


Once we have an ordered list of documents we will announce working 
group adoption requests and we will move forward with our work.  
It’s going to be a busy year, 2019!


Registry Reporting Repository
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

Registry Reporting Structure
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/

Domain Fee Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/

Registry Transaction Report
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/

Registry Domain Inventory Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/

Registry Domain Drop Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report

Registry Unavailable Domain Report
https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/

Registry Maintenance Notifications
https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/

Unhandled Namespaces
https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces

Data Set File Format
https://datatracker.ietf.org/doc/draft-gould-regext-dataset/

Login Security
https://datatracker.ietf.org/doc/draft-gould-regext-login-security/

Login Security Policy
https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/

Federated Authentication for RDAP
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/

RDAP Partial Response
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/

RDAP Search
https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/

RDAP Reverse Search
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/

RDAP Sorting and Paging
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/

Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/

Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/

Third Party DNS Operator to Registrar/Registry
https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

Verification Code
https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/

IDN Table Mapping
https://datatracker.ietf.org/doc/draft-gould-idn-table/


ON HOLD PENDING EXTERNAL ACTIONS

Launch Phase Policy
https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy/

Registry Mapping
https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry/


Antoin and Jim

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-change-poll-10: (with DISCUSS and COMMENT)

[Gould, James]

Benjamin,

Thank you for your review and feedback.  I provide responses to your feedback 
embedded below.
  
—
 
JG



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

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

Verisign.com  

On 12/7/18, 5:52 AM, "Benjamin Kaduk"  wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-change-poll-10: 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-regext-change-poll/



--
DISCUSS:
--

This is a fairly minor point, but the text of Section 2.3 implies that 
there is
a distinct list of identifier types that the server MAY use (and thus that 
there would
be a protocol element to convey such an identifier type), but the actual 
schema in
Section 4.1 is clear that the  element is just a freeform 
token with
some modest length restrictions (i.e., no place for internal structure).  
I'd like to
hear from others on the IESG whether the text about the schema used being up
to server policy is enough to make this clear, or we think there is some 
level of
internal inconsistency in the document to be rectified.

JG - I'll provide a little bit more clarification around the basis for the use 
of a freeform token for the  element.  The  
element is meant for audit purposes and is not meant for driving client-side 
logic, so use of a freeform token based on server policy is the best fit.  This 
is similar to the use of the  and  elements in RFC 
5731, where identifying who created the domain name or updated the domain name 
is returned for audit purposes using a freeform token. 

--
COMMENT:
--

Thanks for the generally well-written document!

There are several places in the document where we read about a "list of 
[...]
values includes" that is in fact required to be one of a fixed enumerated 
set
of values.  In such cases I would suggest "comprises" or "is" rather than 
"includes",
which could be taken to indicate the possibility of additional values being 
defined
at a later time.  Section 2.1 has multiple instances of this, and Section 
3.12. as well.

JG - Thanks, I see your point that using "include" can mean that there may be 
more.  I like the option of "is".  I'll make that change in the following 
places:
Section 2.1: "The enumerated list of  values include:" to 
"The enumerated list of  values is:"
Section 3.1.2: "The enumerated list of case types include:" to " The enumerated 
list of case types is:"

Section 2.2

Maybe state explicitly what it's inserted into, for clarity.

JG - I can update "... MUST be inserted prior to ..." to "... MUST be inserted 
into the message queue prior to ..."

Section 2.3

"CSR" could expand to either "Customer Support Representative" or
"Certificate Signing Request" for some people.  I don't know if there's
better name to suggest.

JG - I believe the reference to "CSR" as "Customer Support Representative" is 
pretty standard in the domain name industry with no confusion to a "CSR" in the 
digital certificate industry.  

Section 2.4

I don't know if it's worth saying anything that would remind recipients of
their (non-?)obligation to accept time values that correspond to leap
seconds, but IIRC we've seen cases in the past of software that chokes when
presented with leap-second timestamps.

JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - 5733) that 
include timestamps, and I'm not aware of any EPP software issues associated 
with leap-second timestamps that warrants a reminder in this EPP draft.  


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

Re: [regext] list of documents to consider for working group adoption

[Gould, James]

Jim,

The following is already a REGEXT working group document:

Verification Code
https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/

The following can be moved to the ON HOLD PENDING EXTERNAL ACTIONS list:

Login Security Policy (Extension of Registry Mapping) 
https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/

The following can be removed:

IDN Table Mapping - This draft would be needed if draft-ietf-eppext-idnmap 
progressed as a working group document.
https://datatracker.ietf.org/doc/draft-gould-idn-table/
 
—
 
JG



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

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

Verisign.com  

On 12/10/18, 11:43 AM, "regext on behalf of James Galvin" 
 wrote:

Thanks to Scott, James, and Tobias.  The updated document list is 
included below.


On 7 Dec 2018, at 9:38, James Galvin wrote:

> Included below is the list of potential documents and topics this 
> working group could adopt.  The first step in moving forward is to 
> make sure we have a complete list.  We are asking folks to review this 
> list and make sure we have not missed anything.  We are allowing one 
> week for this review, until Friday 14 December 2018.  During this time 
> please do ask questions about documents or topics.
>
> The next step will be for the working group members to indicate their 
> top 5 choices of documents to move forward.  Recall that 5 is the 
> maximum number of milestones suggested for us to have open at a time.  
> If there is discussion to be had about this number please start a new 
> email thread and we will see where it goes.
>
> We will do this with a Doodle poll.  Hopefully you are familiar with 
> this.  We will setup each document as a choice and you’ll be asked 
> to select up to 5 documents.  In Doodle, you can select Yes, No, or 
> IfNeedBe.  You can use the IfNeedBe option to indicate documents that 
> you support but not as your top 5.  We will open this Doodle poll 
> before the Christmas holiday and leave it open through Friday, 11 
> January.  That should be plenty of time to get past holiday and 
> vacation time that many folks will have during this time.
>
> Once we have an ordered list of documents we will announce working 
> group adoption requests and we will move forward with our work.  
> It’s going to be a busy year, 2019!

Registry Reporting Repository

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

Registry Reporting Structure

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/

Domain Fee Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/

Registry Transaction Report

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/

Registry Domain Inventory Report

https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/

Registry Domain Drop Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report

Registry Unavailable Domain Report

https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/

Registry Maintenance Notifications
https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/

Unhandled Namespaces
https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces

Data Set File Format
https://datatracker.ietf.org/doc/draft-gould-regext-dataset/

Login Security
https://datatracker.ietf.org/doc/draft-gould-regext-login-security/

Login Security Policy
https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/

Federated Authentication for RDAP
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/

RDAP Partial Response

https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/

RDAP Search
https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/

RDAP Reverse Search
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/

RDAP Sorting and Paging

https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/

Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/

Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/

Third Party DNS Operator to Registrar/Registry

https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

Verification Code
https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/
  

[regext] I-D Action: draft-ietf-regext-change-poll-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
Authors : James Gould
  Kal Feher
Filename: draft-ietf-regext-change-poll-11.txt
Pages   : 27
Date: 2018-12-10

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension for notifying clients of operations on client-sponsored
   objects that were not initiated by the client through EPP.  These
   operations may include contractual or policy requirements including
   but not limited to regular batch processes, customer support actions,
   Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
   Suspension (URS) actions, court-directed actions, and bulk updates
   based on customer requests.  Since the client is not directly
   involved or knowledgable of these operations, the extension is used
   along with an EPP object mapping to provide the resulting state of
   the post-operation object, and optionally a pre-operation object,
   with the operation meta-data of what, when, who, and why.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-11
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-11


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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-change-poll-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Thanks; this sounds like a good path forward.  I'll note that I'm on PTO
this week, so I may be slow to respond to a new rev being issued.

-Benjamin

On Mon, Dec 10, 2018 at 04:48:18PM +, Gould, James wrote:
> Benjamin,
> 
> Thank you for your review and feedback.  I provide responses to your feedback 
> embedded below.
>   
> —
>  
> JG
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com  
> 
> On 12/7/18, 5:52 AM, "Benjamin Kaduk"  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-change-poll-10: 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-regext-change-poll/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is a fairly minor point, but the text of Section 2.3 implies that 
> there is
> a distinct list of identifier types that the server MAY use (and thus 
> that there would
> be a protocol element to convey such an identifier type), but the actual 
> schema in
> Section 4.1 is clear that the  element is just a freeform 
> token with
> some modest length restrictions (i.e., no place for internal structure).  
> I'd like to
> hear from others on the IESG whether the text about the schema used being 
> up
> to server policy is enough to make this clear, or we think there is some 
> level of
> internal inconsistency in the document to be rectified.
> 
> JG - I'll provide a little bit more clarification around the basis for the 
> use of a freeform token for the  element.  The 
>  element is meant for audit purposes and is not meant for 
> driving client-side logic, so use of a freeform token based on server policy 
> is the best fit.  This is similar to the use of the  and 
>  elements in RFC 5731, where identifying who created the domain 
> name or updated the domain name is returned for audit purposes using a 
> freeform token. 
> 
> --
> COMMENT:
> --
> 
> Thanks for the generally well-written document!
> 
> There are several places in the document where we read about a "list of 
> [...]
> values includes" that is in fact required to be one of a fixed enumerated 
> set
> of values.  In such cases I would suggest "comprises" or "is" rather than 
> "includes",
> which could be taken to indicate the possibility of additional values 
> being defined
> at a later time.  Section 2.1 has multiple instances of this, and Section 
> 3.12. as well.
> 
> JG - Thanks, I see your point that using "include" can mean that there may be 
> more.  I like the option of "is".  I'll make that change in the following 
> places:
> Section 2.1: "The enumerated list of  values include:" 
> to "The enumerated list of  values is:"
> Section 3.1.2: "The enumerated list of case types include:" to " The 
> enumerated list of case types is:"
> 
> Section 2.2
> 
> Maybe state explicitly what it's inserted into, for clarity.
> 
> JG - I can update "... MUST be inserted prior to ..." to "... MUST be 
> inserted into the message queue prior to ..."
> 
> Section 2.3
> 
> "CSR" could expand to either "Customer Support Representative" or
> "Certificate Signing Request" for some people.  I don't know if there's
> better name to suggest.
> 
> JG - I believe the reference to "CSR" as "Customer Support Representative" is 
> pretty standard in the domain name industry with no confusion to a "CSR" in 
> the digital certificate industry.  
> 
> Section 2.4
> 
> I don't know if it's worth saying anything that would remind recipients of
> their (non-?)obligation to accept time values that correspond to leap
> seconds, but IIRC we've seen cases in the past of software that chokes 
> when
> presented with leap-second timestamps.
> 
> JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - 5733) that 
> include timestamps, and I'm not aware of any EPP software issues associated 
> with leap-second timestamps that warrants a reminder in this EPP draft.  
> 
> 

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-change-poll-10: (with DISCUSS and COMMENT)

[Patrick Mevzek]

On Mon, Dec 10, 2018, at 11:48, Gould, James wrote:
> Section 2.3
> 
> "CSR" could expand to either "Customer Support Representative" or
> "Certificate Signing Request" for some people.  I don't know if there's
> better name to suggest.
> 
> JG - I believe the reference to "CSR" as "Customer Support 
> Representative" is pretty standard in the domain name industry with no 
> confusion to a "CSR" in the digital certificate industry.  

I kind of disagree but it is a minor point and I believe that the context
provides enough disambiguitation.
There is in general possible confusion as there is overlap between the domain 
name business and the digital certificate issuance business at least for two 
reasons: many certificates are DV so they directly depend on domain names and 
multiple domain name registries and registrars are also Certificate Authorities.

However I really do not see also what we gain by the acronym we could as well 
put
Customer Service Representative
or
Support Agent
or
Customer Care
or whatever, in full, instead of an acronym there, so that the example is 
complete.

> Section 2.4
> 
> I don't know if it's worth saying anything that would remind recipients of
> their (non-?)obligation to accept time values that correspond to leap
> seconds, but IIRC we've seen cases in the past of software that chokes 
> when
> presented with leap-second timestamps.
> 
> JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - 
> 5733) that include timestamps, and I'm not aware of any EPP software 
> issues associated with leap-second timestamps that warrants a reminder 
> in this EPP draft.  

I agree with James, for better or worse, no other EPP documents go into such 
territories
as leap-second and this specification is no more "time" oriented than the others
so it makes no specific sense to start here talking about leap seconds.

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Patrick Mevzek]

On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:
> > * Ensure that the hostAddr model of RFC 5731 is supported 
> > * 
> > *Discussion*
> >  * In the case of a zone that supports domain:hostAddr instead of 
> > domain:hostObj, 
> 
> No. It is not "instead".
> Have a look at the example on page 19 of some registry documentation
> at 
> https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

[..]

> The purpose of draft-gould-carney-regext-registry and the policy 
> extensions is to define the policies around the SHOULDs, MAYs, and 
> options included in extension RFCs, I-Ds, custom extensions, and to 
> define the server-specific policies.  If a registry chooses not to 
> follow the MUSTs in the extensions, that is their choice.  They can 
> define their custom, non-compliant policies in a server-specific policy 
> extension of draft-gould-carney-regext-registry.  Custom policy 
> extensions can be created that define system-level and zone-level 
> policies that don't need to go through the IETF.  There is no need to 
> attempt to address non-compliant policies in the standards track I-Ds.  

I think you are missing the point I try to raise here.
It is of course very easy to dismiss this specific case (but there are tons of 
others)
because the RFC says "MUST", and the case does not follow it, so it is deemed 
invalid
per RFC specifications and can then be ignored.
Technically, yes.
But this has consequences for the future.

First, let me reiterate how important I think this extension is, and I wished we
had it many years ago already. With it, life of registrars would be 
tremendously easier. Which would then also make registries life easier.

**IF** (and this is the big if and the core of my point) it gets implemented, 
and this is where I fear problems, even more so because there is basically no 
discussion
on this list from other registries about it.

For me the future can morph into the following cases:

1) a registry is fully conformant with all RFCs and hence could implement this
extension as is without difficulties. It is just a policy/business/marketing 
case
to decide to implement it or not, the specification is not a barrier

2) registries that decided not to implement it anyway, for whatever reasons and 
case they are in

3) registries that DO NOT respect all RFCs to the letter and/or are in cases 
not handled by this new extension and that are thinking about implementing it 
or not.
If they want to implement it they have the choice:
a) either to change their policies and business rules that either contradicts 
core
EPP documents or are incompatible with the extension as written right now
b) or to create **another** EPP extension just to code for the differences 
between the kind of policies that can be encoded in your extension and the 
registry policies that do not fit in

The above are facts, the below are my assumptions.

- case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall 
in this case
- case 2 is irrelevant for this discussion as nothing we discuss can change that
- case 3 is the interesting point, and my assumption is that this will group 
basically all ccTLDs, and my further assumptions are that of course registries 
will not change their policies just because this extension is not tailored to 
them (so 3a will mostly be empty) and I doubt many will go the length of 
writing a new extension just to codify their policies (so 3b will be negligible)
[BTW 3b introduces again the exact same problem we had with EPP extensions 
since the beginning: fragmentation. Multiple registries have a "trade" 
operation for example. To encode that as policy, there is a risk each one 
drafting an extension for it, and then you come back to the case of multiple 
non-interoperable extensions that do the same things which is a nightmare]

So I fear that at the end we will have something beautiful that caters for all 
the
generic/simple cases, but that left out all complicated cases, and hence the 
implementation will not be widespread.

The fact that no registry claimed to be willing to implement it or to write an 
extension for their own policy is very troublesome for me. But maybe it 
happened in private or will be announced in the future.


-- 
  Patrick Mevzek

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

[regext] =?UTF-8?Q?Re:__Tidbits_after_monday_meeting, _related_to_registry?= mapping extension => DOMAIN

[Patrick Mevzek]

Hello,

Back in July I sent group of emails with details seen in the wild that may need 
to be in the extension, or not.
I am only responding to this one about the form in fact and not the content, 
because I was kind of surprised by various points in the replies I got like:

> How many registries do this (many, some, few, or just one)?  

This is the first time I see a count of registries being asked to finally 
decide how to implement something or not.

In fact recent cases show that we did exactly the opposite: for the fee 
extension and the very late inclusion of the standard attribute, if we 
summarize things we had
- one registrar asking for it but not really promoting it nor participating on 
discussions
- 2 registries saying basically "it is optional, we will not use it, so we are 
neutral to it"
- one client side implementor (me) and one registry saying: this lacks a true 
purpose and is dangerous for interoperability.

Result: it passed, the attribute was added!

Based on that, I do not see why now we should dictate what goes in or not based 
on how it is used in the wild. I think you have basically three options:
- encode only exactly what core EPP documents allow
- try to filter things and define those used often enough to warrant being 
included from those used by only "1" registry that are put aside and would need 
an extension
- put everything in.

We are not doing 1) because last time I read the specification there are things 
in it that are clearly not in EPP core documents (like "custom" contact types).
We seem to be trying to do 2) which is very dangerous because it leads to 
questions like above and if you match that by the very low amount of exchanges 
on this list, I really fail to see how we can make sure to take the proper 
decisions as a group.
And of course, by "extension" 3) would be as well difficult to reach.

But at least my position is basicall a 2) without treating some cases as second 
class citizen just because they are rare or  further away from "pure" EPP. Of 
course it would help if each registry participated and were champions for their 
own cases but obviously we are not there nor will we be in a short future.

Or otherwise we really do 1) but then multiple things will need to be removed 
(custome contact types, privacy/proxy, etc. I listed some in my previous 
emails).

So, I do not think it is useful for this working group that I reply extensively 
on each point, where I mostly detailed what is happening in the wild currently, 
that we may like or dislike on an engineer level, but then the question I think 
is really how much we want this "registry policy" extension to be implemented 
by many registries, and not by the ones closer to "standard" EPP.

Even if I may not have phrased things good enough, I hope the above will have 
succeeded in trying to raise awareness about the so many different cases in the 
wild and the need to try to "accomodate" if we want success both in term of 
numbers of implementations and avoiding fragmentations (where multiple 
extensions exist to do exactly the same thing in fact).

-- 
  Patrick Mevzek

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

Re: [regext] list of documents to consider for working group adoption

[Patrick Mevzek]

Hello,

Sorry to be probably again in the minority and the dissonant voice here, but I 
do not understand this:

On Fri, Dec 7, 2018, at 10:49, James Galvin wrote:
> The purpose of the list was to include everything that exists or that 
> has passed through the working group.  I have to admit it was more than 
> I expected when we created the list.
> 
> In any case, the right thing to do is simply not vote for any document 
> you do not want to move forward.

To me, this process feel completely backwards :-(

As described, it makes sense to me if:
- we have a wide community of people
- with far enough time on their hands
- to read ~20 technical documents
- compare their merits
- and finally select 5 to "promote" to push to the working group
- of course all in some specific tight deadline.

I believe we are absolutely in the opposite case and I fear the outcome of this 
process will not have the expected results.

First, I think the burden should be on the authors to at least present the 
document on the list (which is not even the case for some of them), in order to 
convince people that there is indeed a problem to solve (first important point) 
and that their solution or beginning of a solution makes sense. If their 
arguments are clear and correct, people would then be enthousiastic to add them 
as working group elements and work on them.

Instead by just trying to be exhaustive and let people choose among everything 
you achieve two things:
- you show each document as similar to others in term of usefulness that is 
maturity, scope of the problem, precise solution to it, etc. (and they are 
obviously not all equal on these points)
- you accept that documents are basically worked on elsewhere, never discussed 
here, and coming late (which means it may be more difficult to work, as a 
group, on them because many design choices would already be set in stone by 
then). Which has to me the very unfortunate result that the working group just 
becomes an IETF stamp for an EPP extension.
Even if the same people as here are working on the document elsewhere before 
presenting it here, what is then the value or added value of this working 
group, if it is basically just to make sure it fits an RFC structure, follows 
all guidelines, register what needs to be registered at IANA, etc. which is 
basically no more an engineering task but merely an editorial one?
This is not the only reason but I think this also explains in the very low 
participation we see and the difficulty to find editors, shepherds, etc. (and 
of course it is a vicious circle as the low participation here could be taken 
by some as an indication that they should work on their documents elsewhere to 
make progress).

Second, beside authors of course which are already motivated to do so, anyone 
may be free to promote or vote on any document of couse to be a working group 
document, but what would that mean (for the working group and the specific 
documents)?

Instead, why not do like it is done in other working groups and ask people to 
speak for a document **if and only if** they kind of informally pledge to work 
on it in some way which may mean:
- reading it, and the future other versions
- being at least able to assess if the document is good enough to go to WGLC 
for example
and/or to summarize it broadly (problem to be solved, strong points of the 
solution offered, points remaining to discuss, other options)
- provide feedback, if possible, at various levels (either just alternate ideas 
or specific detailed implementation point to work on, etc.)
- act as an editor (non-technical feedback)
- pledge or express strong interest into implementating it or putting enough 
energy to convince a third party to implement it
- identify that it may be related to some other kind of document (in this 
working group or not), or that other actors may already have solved the same 
problem or working on it, etc. and trying to liaise between everyone
- etc. (there are many ways to participate, sometimes just sending emails to 
the authors to ask where they are at, what is blocking, etc. can give the 
authors a boost of motivation - seeing that others care too about the document 
- to work further on it)

This would also clearly show interest for it: if people are saying "yes, I 
agree to spend some of my time making sure this documents advance as an IETF 
document" then it proves real usefulness and support by the "community" for it. 
A very useful information to be added later on in the shepherd write-up ;-)


Also the discussion started already previously (but did not go very far I 
think) and I think we (I) suggested already that having an Implementation 
Section or at least clear intentions to work on implementations or asking 
others to work on some could be used, among other factors, as a basis to see if 
a document should be considered by the working group or not.

To be honest right now I prefer to devote the little personal time I have to 
try imple