RegExt at IETF103
REGEXT has been a quiet working group for some time. The nature of the participants and the technology means that interoperability is not strictly important to the business and political interests of the organisations interested in EPP. Luckily IETF 103 had REGEXT's first true controversy to keep things interesting.
draft-ietf-regext-verificationcode
In recent times there have been several attempts by registries to develop solutions which conform to the Chinese government's requirements for Chinese citizens wishing to purchase domain names. Needless to say that those requirements involve verifiable PII. There's two models of such solutions that I'm aware of:
Validate first, register second.
In this model the Registrar receives the relevant registrant information, sends it to a Verification Service Provider who conducts the relevant checks and supplies a code on success. This code is then submitted by the registrar to the registry as part of the domain create process. This is the model used in draft-ietf-regext-verificationcode
Register first, validate second.
In this model, a registrar registers the domain on behalf of a registrant and supplies additional information to the registry. The registry then supplies a 3rd party with the relevant PII and that 3rd party ultimately replies to the registry enabling the registrant full use of the domain (it's in a pending state or server hold in the meantime).
HRPC and RFC8280
Until the REGEXT meeting at IETF103 I'd never heard of RFC8280 (it's an informational document). It's long and I havent read it all, but it finishes with a questionaire intended to aid protocol implementers in ensuring that they are aware of any Human Rights impact of their drafts. Apparently it also contains some guidelines on creating a HRPC section in RFC documents, although I havent found that in my brief read. Perhaps one simply uses the questionaire to create such a section.
The HRPC research group has strongly suggested that a HRPC section is appropriate for the verificationcode draft. To my knowledge, this would be the first working document with such a section.
Existential crises or some extra words?
Objections to adding the section have ranged from a desire to avoid experimenting with this particular draft to an insistence that a protocol document should be as neutral as possible and entirely avoid discussion of the purpose of its deployment or the impacts upon those whose data is part of the workflow.
Proponents of the section have suggested that documenting the issues the draft creates is a valuable addition to the draft. I should note that early suggestions for the content of an HRPC section were most certainly not neutral in tone.
If you're not first, you're last.
I disagree with the suggestion that the HRPC section should or should not be included based on whether it has been done before. This is the IETF, shying away from something simply because it's new seems to be the opposite of why we're all in these working groups.
On the otherhand, forcing a document author to include something ill defined or irrelevant also strikes me as a bad idea.
Where to now?
Debate continues on the list and hopefully it is resolved within the REGEXT working group. However I can't help but think that this is an experiment by the HRPC research group and I feel for the document authors who were certainly unprepared for the moralistic barage they received initially. The discussion has toned down in recent times and hopefully it stays focused on the key points:
- With some recent changes to the draft is an HRPC section even needed?
- If the section is still needed what goes in there? RFC8280 is hard to parse.
Many in the working group and I suspect also in the HRPC research group, would like this discussion to move to the broader IETF community. While I agree that such a discussion might prove useful, I personally think that each working group should understand their own technologies well enough to comment on their impacts to direct users and owners of data the technology carries or transforms. In most cases (not all) this seems to align with the privacy considerations which has seen some use in recent documents within the IETF.
Keep the popcorn handy, this isn't done yet. I suspect there'll be more posts on this topic in the future.