RESTful Provisioning Protocol
charter-ietf-rpp-01

[Ballot comment]
Just two (related) comments: 
1.  I would either spell out 'WAF' or just eliminate it (there are plenty of examples without it).
2.  scrub this for acronyms that are not on the list (terms w/ '*' @ https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list) - REST, RDAP, for example.

update:  Thanks for addressing these comments.

[Ballot block]

Bellow are the comments and observations I would like to see resolved -

#  I didn't find much difference between these two following considerations and outcomes, in the charter

    1. The RPP WG also considers functional equivalents of registered EPP extensions, either through similar RPP extensions or incorporating them into the core of the protocol.

    2. The RPP WG considers RPP extensions that are functional equivalents of registered EPP extensions in the construction of requirements.

If 1. and 2. are different then we need to spell them out.

# It says- The RPP WG is tasked with creating a series of specifications to be known collectively as the RESTful Provisioning Protocol (RPP).

    This is a given thing for a IETF working group to produce specifications, can we be more specific about the speciallity about these series of specifications that makes it worth noting in the charter?

# It says - The RPP working group is focused on designing a new protocol intended to co-exist alongside EPP, supporting diverse needs in the ecosystem.

  If it is just one protocol then why do we need series of specificaitions? or the intention is to have "a set of new protocols"?

[Ballot comment]

Bellow are the comments and observations I would like to see resolved -

#  I didn't find much difference between these two following considerations and outcomes, in the charter

    1. The RPP WG also considers functional equivalents of registered EPP extensions, either through similar RPP extensions or incorporating them into the core of the protocol.

    2. The RPP WG considers RPP extensions that are functional equivalents of registered EPP extensions in the construction of requirements.

If 1. and 2. are different then we need to spell them out.

# It says- The RPP WG is tasked with creating a series of specifications to be known collectively as the RESTful Provisioning Protocol (RPP).

    This is a given thing for a IETF working group to produce specifications, can we be more specific about the speciallity about these series of specifications that makes it worth noting in the charter?

# It says - The RPP working group is focused on designing a new protocol intended to co-exist alongside EPP, supporting diverse needs in the ecosystem.

  If it is just one protocol then why do we need series of specificaitions? or the intention is to have "a set of new protocols"?

[Ballot comment]
- You could drop “functional” from this sentence without loss of generality, and it wouldn’t make my eyelid twitch then: “The RPP WG considers functional equivalents of functionality from EPP”.

- Because of the limitations of English grammar, I found this more challenging to understand than is strictly desirable: “However, the RPP WG publishes its usage of tools beyond the datatracker and mailing lists on its wiki.” How about something like, “However, the RPP WG may also make use of tools beyond the datatracker and mailing lists. Any such will be published on its wiki.”

- I suppose some preliminary milestones are in order?

[Ballot comment]
The charter did not clarify one thing. What happens if EPP defines a new extension to the protocol? Does RPP follow suit, or do they diverge at that point?

[Ballot comment]
It's peculiar, I think, that we're creating a proposed standard that will operate alongside an existing proposed standard that basically provides the same service, the newer being simply a modernized version of the other, with no plan to intentionally obsolete the other one.  Is the idea to let market forces decide?

[Ballot comment]
** Per “This evolution has already started with some Country Code Top Level Domains (ccTLDs)”, what evolution?  Is it use of JSON and REST or RDAP?

** Per “First production deployments of this approach have seen adoption by both new and existing clients, where a preference has been noted for this approach.”  Same question as for the previous sentence.

** Per “Industry experience of the ccTLDs with non-EPP provisioning protocols and use cases from EPP may influence the outputs of the RPP WG …”: how does this text about industry experience scope, constrain or set requirements for the WG?  Any past experience could influence the outputs of the WG?  Is this needed?

** What is the distinct scope being proposed with these two sentences.  They appear to be saying the same thing:
-- “The RPP WG also considers functional equivalents of registered EPP extensions, either through similar RPP extensions or incorporating them into the core of the protocol.”

-- “The RPP WG considers RPP extensions that are functional equivalents of registered EPP extensions in the construction of requirements.”

** What are the bound of “New functionalities, not having any equivalents in EPP, may be defined for RPP.”?

** Per “The charter in datatracker is the source of truth for all official working group process requirements”: what are “working group process requirements”?  A number of other IETF documents described WG processes and procedures.

** Per “All consensus decisions are conducted on the mailing list”: could the rationale for this sentence be explained. It is a restatement of what is true for every WG.

** Per “Analysis of the functionality included and commonly used in core EPP for domain names, hosts and contacts (RFC5730, 5731, 5732, and 5733) is developed to support the deliverables.”: what is the form that “analysis” takes?

[Ballot comment]
** Per “This evolution has already started with some Country Code Top Level Domains (ccTLDs)”, what evolution?  Is it use of JSON and REST or RDAP?

** Per “First production deployments of this approach have seen adoption by both new and existing clients, where a preference has been noted for this approach.”  Same question as for the previous sentence.

** Per “Industry experience of the ccTLDs with non-EPP provisioning protocols and use cases from EPP may influence the outputs of the RPP WG …”: how does this text about industry experience scope, constrain or set requirements for the WG?  Any past experience could influence the outputs of the WG?  Is this needed?

** What is the distinct scope being proposed with these two sentences.  They appear to be saying the same thing:
-- “The RPP WG also considers functional equivalents of registered EPP extensions, either through similar RPP extensions or incorporating them into the core of the protocol.”

-- “The RPP WG considers RPP extensions that are functional equivalents of registered EPP extensions in the construction of requirements.”

** What are the bound of “New functionalities, not having any equivalents in EPP, may be defined for RPP.”?

** Per “The charter in datatracker is the source of truth for all official working group process requirements”: what are “working group process requirements”?  A number of other IETF documents described WG processes and procedures.

** Per “All consensus decisions are conducted on the mailing list”: could the rationale for this sentence be explained. It is a restatements of what is true for every WG.

** Per “Analysis of the functionality included and commonly used in core EPP for domain names, hosts and contacts (RFC5730, 5731, 5732, and 5733) is developed to support the deliverables.”: what is the form that “analysis” takes?

[Ballot block]
** Per “The RPP WG is tasked with creating a series of specifications to be known collectively as the RESTful Provisioning Protocol (RPP). These specifications target a REST architecture high on the Richardson Maturity Model using HTTPS and JSON.”: How does the second sentence scope the work without being specific on which level of maturity is targeted as a requirement?

** Per “In addition to use cases, scenarios, and extension mechanisms for domain name registration, the RPP WG considers features and extension mechanisms useful for other types of Internet registration areas.” – Can the scope of this be shrunk?  What constitutes “Internet registration areas”?  Could this be left to future recharter?

[Ballot comment]
** Per “This evolution has already started with some Country Code Top Level Domains (ccTLDs)”, what evolution?  Is it use of JSON and REST or RDAP?

** Per “First production deployments of this approach have seen adoption by both new and existing clients, where a preference has been noted for this approach.”  Same question as for the previous sentence.

** Per “Industry experience of the ccTLDs with non-EPP provisioning protocols and use cases from EPP may influence the outputs of the RPP WG …”: how does this text about industry experience scope, constrain or set requirements for the WG?  Any past experience could influence the outputs of the WG?  Is this needed?

** What is the distinct scope being proposed with these two sentences.  They appear to be saying the same thing:
-- “The RPP WG also considers functional equivalents of registered EPP extensions, either through similar RPP extensions or incorporating them into the core of the protocol.”

-- “The RPP WG considers RPP extensions that are functional equivalents of registered EPP extensions in the construction of requirements.”

** What are the bound of “New functionalities, not having any equivalents in EPP, may be defined for RPP.”?

** Per “The charter in datatracker is the source of truth for all official working group process requirements”: what are “working group process requirements”?  A number of other IETF documents described WG processes and procedures.

** Per “All consensus decisions are conducted on the mailing list”: why is this sentence here?  They are restatements of what is true for every WG?

** Per “Analysis of the functionality included and commonly used in core EPP for domain names, hosts and contacts (RFC5730, 5731, 5732, and 5733) is developed to support the deliverables.” : what is the form that “analysis” takes?

[Ballot comment]
A rather long but easy to read charter.

Is there a reason why some terms (e.g., REST, JSON) are associated to a link (unsure whether it will fly when becoming the actual charter) while others (e.g., OpenAI, RDAP) are not ?

While I am not at all familiar with "Richardson Maturity Model", I wonder whether `target ... high on the Richardson Maturity Model` is too fuzzy to be in a charter.

It is a little unclear to me where the following will happen `New functionalities, not having any equivalents in EPP, may be defined for RPP.` end of the section seems to imply REGEXT.

`The charter in datatracker is the source of truth for all official working group process requirements.` isn't this obvious for any WG? Same comment for `All consensus decisions are conducted on the mailing list.`

[Ballot comment]
# Internet AD comments for charter-ietf-rpp-00-01
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

* "New functionalities, not having any equivalents in EPP, may be defined
  for RPP."

  I would suggest saying such things are out of scope until the main RPP
  documents have finished IESG review and have been sent to the RFC Editor.

  Just something to consider.

[Ballot comment]
Just two (related) comments: 
1.  I would either spell out 'WAF' or just eliminate it (there are plenty of examples without it).
2.  scrub this for acronyms that are not on the list (terms w/ '*' @ https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list) - REST, RDAP, for example.

RPP had a BoF at IETF 121 - https://www.youtube.com/watch?v=eSAQcS1cVSM&t=1449s

There were no objections on the list to proceeding with charter text that was posted for intial review here:

https://mailarchive.ietf.org/arch/msg/rpp/J1LBnlGHTTx60MzmjBOUWcW82Ic/