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