Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping
RFC 8056
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
(Alexey Melnikov; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
Agree with Mirja that other than the final mapping, section 2 seems mostly redundant with the IANA considerations section and could be removed.
(Ben Campbell; former steering group member) No Objection
Maybe it's obvious to everyone else, but what is the goal of these mappings? It would help to have a paragraph or two explaining that. (Or did I miss something?) Are the mappings reversible? -1, last paragraph: The MUST probably doesn't need a 2119 keyword. IIUC, it's a requirement on this draft, not on implementations.
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com> performed the opsdir review
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
A few minor comments: - I guess this doc should cite RFC5730 and RFC7482 (?) in the intro...? - I would propose to directly put the link to the registation in the introduction instead of using a citation ([rdap-json-values]) because I initially didn't realize that this not a doc. - And effectively you could even remove section 2 mostly or potentially even competely as all information are given (word-for-word) in the IANA consideration section. And thanks for the nice in in-depth shepherd write-up!
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection