Re: [regext] regarding adopting new documents and milestones

[Patrick Mevzek <[e-mail]>]

On Fri, Oct 19, 2018, at 15:15, James Galvin wrote:
> 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.

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/


> We are asking the group to think about the following questions.
> 
> 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).


> 3. Of the 8 documents being proposed for adoption, which ones are the 
> 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
  [e-mail]