Subject: [regext] regarding adopting new documents and milestones

From: "James Galvin" <[email-masked]>
Date: Fri, 19 Oct 2018 10:15:09 -0400

By now you should have seen the draft agenda for IETF103.  On it you 
will see 8 requests for adopting new documents as working group 
milestones.  The chairs are concerned that we should not adopt quite 
that many new documents all at once.

If you look at our current milestone list, there are 3 open milestones.  
One of these (“EPP Domain Name Mapping Extension for Bundling 
Registration”) we expect to close quite soon as the shepherd is 
actively preparing the writeup.  This leaves us with 2 milestones we may 
wish to reconsider whether to keep or not.

The chairs are proposing that the working group should not have more 
than 5 open milestones at a time.  We can discuss if that’s the right 
number but for now we will use that as our starting point.

Given that two milestones will remain on our list we will only have room 
for 3 new documents to adopt.

We are asking the group to think about the following questions.

1. How many open milestones should we allow ourselves to have?

2. Do we want to reconsider any currently open milestones?

3. Of the 8 documents being proposed for adoption, which ones are the 
priorities, i.e., the documents we want to adopt first?

The last item on our agenda is a discussion of our milestones.  We will 
use this time to consider the questions listed above.

Please note, whatever priorities we create from this discussion will 
need to be brought to the mailing list for final agreement.  We will 
follow that with a separate individual request for adoption of each 
document selected by the working group.

If you have any questions or comments please do respond to the list.

Thanks,

Antoin and Jim

---

From: Gustavo Lozano <[email-masked]>
Date: Sat, 27 Oct 2018 00:16:54 +0000

Antoin, Jim, et.al.

My understanding of this message is that only a certain number of I-Ds will be allowed to be adopted as WG documents. 

If my understanding is correct, I feel uncomfortable with defining a number, because it appears to exist a recent enthusiasm for creating I-Ds (probably related to the popularity of registration data privacy in several jurisdictions) and having an artificial gate could push authors and implementers to define the standards outside of the WG/IETF.

My preference is for allowing any I-D, that the WG believes that is a good fit, to be adopted. If a subset of the WG participants or non-participants want to get involved in the development of an I-D that is not part of the milestones, they should be free to do so, and the I-D should be allowed to reach RFC status based on the number of reviewers, running code and the last calls.

Regards,
Gustavo

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of James Galvin
> Sent: Friday, October 19, 2018 07:15
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [Ext] [regext] regarding adopting new documents and milestones
> 
> By now you should have seen the draft agenda for IETF103.  On it you will see 8
> requests for adopting new documents as working group milestones.  The chairs
> are concerned that we should not adopt quite that many new documents all at
> once.
> 
> Registration”) we expect to close quite soon as the shepherd is actively
> preparing the writeup.  This leaves us with 2 milestones we may wish to
> reconsider whether to keep or not.
> 
> The chairs are proposing that the working group should not have more than 5
> open milestones at a time.  We can discuss if that’s the right number but for
> now we will use that as our starting point.
> 
> Given that two milestones will remain on our list we will only have room for 3
> new documents to adopt.
> 
> The last item on our agenda is a discussion of our milestones.  We will use this
> time to consider the questions listed above.
> 
> Please note, whatever priorities we create from this discussion will need to be
> brought to the mailing list for final agreement.  We will follow that with a
> separate individual request for adoption of each document selected by the
> working group.
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Oct 2018 11:40:23 -0500

[as Area Director]

Hi!

While I appreciate that the proposal you've put forth is trying to 
ensure that popular or urgent work doesn't end up getting blocked on 
lower priority items (and pushed into other venues), we have pretty 
solid historical data that shows that the approach you're describing 
leads to very slow progress in moving documents towards publication. 
What's important to keep in mind is that the working group is entirely 
in charge of which milestones to add to its chartered work, and that 
it's possible to remove milestones if you later decide that you need the 
slot for something more important.

The chairs have been very good about working with the working group to 
actively manage which documents should become and stay milestones. As 
this active management approach has led to more regext documents 
reaching the "publication requested" state rather than fewer, it seems 
that it is more likely to stave off the need to publish mechanisms 
outside the IETF than the previous, lower-throughput approach.

/a

---

From: Andrew Newton <[email-masked]>
Date: Mon, 29 Oct 2018 16:21:54 -0400

Perhaps priority should be given to those I-Ds with running code.

-andy
On Mon, Oct 29, 2018 at 12:41 PM Adam Roach <[email-masked]> wrote:
>
> [as Area Director]
>
> Hi!
>
> While I appreciate that the proposal you've put forth is trying to ensure that popular or urgent work doesn't end up getting blocked on lower priority items (and pushed into other venues), we have pretty solid historical data that shows that the approach you're describing leads to very slow progress in moving documents towards publication. What's important to keep in mind is that the working group is entirely in charge of which milestones to add to its chartered work, and that it's possible to remove milestones if you later decide that you need the slot for something more important.
>
> The chairs have been very good about working with the working group to actively manage which documents should become and stay milestones. As this active management approach has led to more regext documents reaching the "publication requested" state rather than fewer, it seems that it is more likely to stave off the need to publish mechanisms outside the IETF than the previous, lower-throughput approach.
>
> /a
>
>

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 31 Oct 2018 05:41:57 +0100

> Perhaps priority should be given to those I-Ds with running code.

This is one of the point I mage in my July message:
https://mailarchive.ietf.org/arch/msg/regext/DuitffLvC4Q5RR32AnN1yDEUEYg

Running code is useful/needed but maybe too high a barrier for an I-D to become a working group document. It can happen during its life I guess, but more important for me would be to have at least 2 completely separate *registries* implementation, which then could be a good idea of something that was in my July message.

In short, not all extensions may become used by more than one registry. As sad as it may be for registrars (if the extension solves a generic issue that happens elsewhere or could benefit elsewhere), it is the state we are in.

However in that, how much of working group energy should be devoted to that, and is the Proposed Standard path really necessary?
Maybe just an addition of the extension in the EPP Extension Registry should be enough?
There are a lot of extensions out there and discussed, and very few recorded in the extension registry. Basically only 3 registries took the effort to add their extensions there.

And as said, sometimes an extension really tailored to one use case and one registry will need a lot of work to be more generic, and various feedback about needs of proper specification and taking care of interoperability might not be so much welcome in fact.

So in summary I could say that I am not in favour of hardcoding any specific number of IDs to work on, but I would advise that 1) not all extensions need to become an RFC, being a proper ID with correct structure and registration in the extension registry is already a very good step and 2) for those wanting to be an RFC and before that wishing for the working group to work on, then they should really make sure to both display that the need spans multiple registries/registrars and that the document is really open to be updated to take into account more generic cases as needed as well as various implementation enhancements that are often only discovered when implementations are done.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 31 Oct 2018 06:28:17 +0100

On Fri, Oct 19, 2018, at 15:15, James Galvin wrote:
> milestones.

Note in passing that it may not be so easy, at least to search in mailboxes because the message with this agenda on October 19th
has a subject of:
"Preliminary agenda for IETF102 Bangkok"
(wrong IETF meeting number)

To simplify discussion, the documents referenced in it are
(I read only 7 of them in it, point 4, I do not know which one is the 8th):

https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/
https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/
https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy/
https://datatracker.ietf.org/doc/draft-gould-regext-login-security/
https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/
https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

> 1. How many open milestones should we allow ourselves to have?

I do not think fixing in stone any single value provide better work. We are a very small team and obviously the resources are thin. In that vain, "forbidding" people to work on a specific subject they want to work on seems counter-intuitive to me.

I believe you should instead ask for each document, who is interested by it, who "pledges"  to work on it, to read it, to provide feedback to authors, etc. Of course none of this is binding, but it can give rough estimates of the energy that can happen behind each document, and it is done like that in other working groups.

If some documents do not get much love from the crowd it may mean that the author first need to convince the working group that there is really an interesting generic case to solve and that his proposition is open for debate and work on it.
 
> 2. Do we want to reconsider any currently open milestones?

The three not being yet submitted for publication are:
draft-ietf-regext-bundling-registration
draft-ietf-regext-validate
draft-ietf-regext-dnsoperator-to-rrr-protocol

Only the first one has an "Implementation Status" section with 2 servers and 1 client (from my reading of the section, it contains other information not really related to current implementation status).

> priorities, i.e., the documents we want to adopt first?

I think you may get as different replies to these two questions as they are participants, so that will be a difficult task. I note also the lack of many replies to your message.

Anyway, as a followup of my previous message that was more generic, while trying not to just give my personal, obviously biaised opinion, I can give the following remarks that may help choosing where it is best to devote the WG energy:

- some documents have not even been presented on the list; if you search by the document name in the list archives you find no mention of it whatsoever
I would expect an author wishing its work to be taken into consideration by the working group makes a least an introduction.
Otherwise this working group may just look like as a rubberstamping authority, appointing standards that were already written elsewhere

- unfortunately being a generic problem but many documents had very low level of discussions yet, and I do not recall having seen a lot of registries, not being the one having written the document, that shared their enthousiasm or possible thinking of implementing it; this is of course difficult to jauge as it does not necessarily happen in public view on a mailing-list, but can be in part related to the Implementation Status section that is discussed in the point just following

- I just looked again at all 7 to see the Implemetnation Status for them if we want to take that into account:

* draft-loffredo-regext-rdap-reverse-search has it, with 1 server implementation
* draft-loffredo-regext-rdap-sorting-and-paging has it, with 2 servers implementations
* draft-gould-casanova-regext-unhandled-namespaces has it, with 1 client (SDK) implementation

The other 4 do not have any Implementation Status data at the moment.

- another axis at which you can look is wether the document clearly tackles a generic problem or instead is very specific to one use case (author and proponents are free to try exposing the use case and how much generic it is).

- in the same way you can think to discriminate between documents that add new features and those that fix or enhance or better specify existing features or corner cases (for me "draft-gould-casanova-regext-unhandled-namespaces" fits in this second case)

I would personnally favor first documents that have been introduced on the list by their authors with clear explanations on the use case, that have implementations (at least started if not done already), that are generic (can apply to more than one registry easily) and that fix/enhance current behavior, before adding new behaviour.

-- 
  Patrick Mevzek
  [email-masked]