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
  p...@dotandco.com

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

Reply via email to