Subject: [regext] Benjamin Kaduk's Abstain on draft-ietf-regext-secure-authinfo-transfer-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 28 Jul 2021 16:24:29 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-secure-authinfo-transfer-07: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for all the updates in response to my previous ballot position.

In the interest of letting the document move forward, I am balloting Abstain
because the document still contains behavior that, while fully specified,
seems to require additional conditional behavior in client implementations
that results in unnecessary fragility of implementation.  The responsible
AD and WG chairs should confirm that the WG does indeed have consensus to
have made this decision, but I have no other grounds to block the document's
publication once that consensus is confirmed.

Copying the point from my previous discuss ballot in order to provide specifics
on the behavior that prompts my Abstain position:

(2) There's also some text in Section 5.3 that I'd like to discuss briefly:

   The registry MUST NOT return any indication of whether the
   authorization information is set or unset to the non-sponsoring
   registrar by not returning the authorization information element in
   the response.  The registry MAY return an indication to the
   sponsoring registrar that the authorization information is set by
   using an empty authorization information value.  The registry MAY
   return an indication to the sponsoring registrar that the
   authorization information is unset by not returning the authorization
   information element.

This seems to be assigning semantics to both absent-authinfo and
empty-authinfo in the <info> response, but is giving *different* semantics
to the response-to-sponsoring-registrar and
response-to-non-sponsoring-registrar cases.  Is there precedent for
changing the semantics of the response based on the identity of the
client like this (not just changing the content of the response)?  Can
we come up with a scheme that provides consistent semantics to all
clients, perhaps based on <domain:null> vs empty <domain:pw> for
unset/set, leaving "element is absent" for the deliberately ambiguous
case?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Jul 2021 16:26:52 -0700

> publication once that consensus is confirmed.

Can the chairs please respond to this point?  I'd like to get something on
the record before we move the document forward.

Thanks,

-MSK, ART AD

Copying the point from my previous discuss ballot in order to provide
> specifics