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? _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
