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

From: James Galvin <[email-masked]>
Date: Mon, 30 Aug 2021 09:43:47 -0400

Excepting from below:

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

The co-Chairs agree we have working group consensus to publish this 
document as specified.  This based on the following four things.

* The text in question has been present in the specification since -01 
was published.  This means it has been before the working group for 
quite some time and there have not been any questions or concerns within 
the working group regarding this text.

* Benjamin’s concern has been visible on the mailing list and everyone 
has had the change to follow the discussion between the Benjamin and 
James Gould, the author.  There has not been any consensus in support of 
the concern.

* Additionally, the question was raised during the working group meeting 
at IETF111.  There was no consensus in support of the concern.

* Finally, Benjamin did change his position to ABSTAIN based on noting 
that the specification is fully specified in its current form and as 
long as the working group has consensus to move forward, he would not 
object.  As noted above, the working group has concensus to move 
forward.

Let us know if the IESG has any additional questions or concerns about 
moving this document forward.

Antoin and Jim

On 28 Jul 2021, at 19:26, Murray S. Kucherawy wrote:

> On Wed, Jul 28, 2021 at 4:24 PM Benjamin Kaduk via Datatracker <
> [email-masked]> wrote:
>
>> 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.
>>
>
> 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
>> 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?
>>