Mirja,
Thanks again for your feedback.
The text says
"If an object requires an Allocation Token and the Allocation
Token does not apply to the object or an object does not require
an Allocation Token, then the server SHOULD return the
availability status as unavailable (e.g., "avail" attribute is
"0" or "false“).“
which includes the case where the "object does not require an Allocation
Token“…?
No, this does not include the case where “object does not require the
Allocation Token”. The protocol leaves that case up to server policy. Would
it help to add the third case below?
“3. If an object does not require an Allocation Token, the server MAY return
the availability status as available (e.g., “avail” attribute is “1” or
“true”).”
This means that we would have the 3 cases covered with the appropriate use of
the MUST, SHOULD, and MAY to support the different levels of server policy
choices. Based on the protocol of providing a “hint”, the passing of an
Allocation Token where the Allocation Token does not apply MUST return an error
on create, so therefore the protocol behavior would be for the server to return
an object that does not require an Allocation Token as unavailable. Providing
the MAY in the server returning an object that does not require an Allocation
Token as available, will provide flexibility for the server policy to define
the behavior.
Do you agree?
> The check command, per RFC 5731, supports many domain names in a single
command, and it provides "a hint that allows a client to anticipate the success
or failure of provisioning an object using the <create> command" . The
Allocation Token in draft-ietf-regext-allocation-token is a single value that
is applied to all domain names, where we don't want the protocol to be overly
strict in defining the availability value. The most strict policy would be to
return all domain names that don't require an Allocation Token or where the
Allocation Token doesn't match as unavailable. Since the Allocation Token may
apply to only one of the domain names in the list, the protocol only requires
(MUST) the server to return an Allocation Token match as available. The
Allocation Token mismatch is treated as a SHOULD and a non-applicable
Allocation Token is undefined to enable server-policy to determine the
behavior. Does this make sense?
Okay, then the SHOULD makes sense. Eventually provide some more explanation
in the draft.
Would adding the 3rd case address the explanation concern?
Thanks,
—
JG
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 8/6/18, 10:26 AM, "Mirja Kuehlewind (IETF)" <[email protected]> wrote:
Hi James,
thanks for the reply.
> Am 06.08.2018 um 15:47 schrieb Gould, James
<[email protected]>:
>
> Mirja,
>
> Thank you for your review and feedback. My responses are embedded below.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [email protected]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 8/6/18, 7:53 AM, "Mirja Kühlewind" <[email protected]> wrote:
>
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-regext-allocation-token-09: No Objection
>
> 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 IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Two quick questions (and I'm really no expert here, so these questions
might be
> stupid):
>
> 1) Why should the check return 'unavailable' if the object does not
require an
> Allocation Token but the check is send with an Allocation Token (sec
3.1.1)? Is
> that obvious to everybody else but me or should that maybe be further
explained
> in the doc? And inline with that, why is it not a MUST to return
'unavailable'
> if a Token is required but the sent token doesn't match?
>
> JG - The draft really doesn't discuss the case where the object does not
require an Allocation Token and the check command includes the Allocation
Token, but it does cover the two cases where the object does require an
Allocation Token and the passed Allocation Token matches (MUST return
available) and doesn't match (SHOULD return unavailable).
The text says
"If an object requires an Allocation Token and the Allocation
Token does not apply to the object or an object does not require
an Allocation Token, then the server SHOULD return the
availability status as unavailable (e.g., "avail" attribute is
"0" or "false“).“
which includes the case where the "object does not require an Allocation
Token“…?
> The check command, per RFC 5731, supports many domain names in a single
command, and it provides "a hint that allows a client to anticipate the success
or failure of provisioning an object using the <create> command" . The
Allocation Token in draft-ietf-regext-allocation-token is a single value that
is applied to all domain names, where we don't want the protocol to be overly
strict in defining the availability value. The most strict policy would be to
return all domain names that don't require an Allocation Token or where the
Allocation Token doesn't match as unavailable. Since the Allocation Token may
apply to only one of the domain names in the list, the protocol only requires
(MUST) the server to return an Allocation Token match as available. The
Allocation Token mismatch is treated as a SHOULD and a non-applicable
Allocation Token is undefined to enable server-policy to determine the
behavior. Does this make sense?
Okay, then the SHOULD makes sense. Eventually provide some more explanation
in the draft.
>
>
> 2) Why is this mechanism not applied to delete, renew, and update?
>
> JG - Allocation is when the server assigns the sponsoring client of an
object based on the use of an Allocation Token credential, which is not
applicable to a delete, a renew, and an update. The common case for allocation
is with the use of the create command and the less common case for allocation
is with the use of the transfer command (e.g., transfer from server to
sponsoring client). The draft did initially include support for an extended
update that defines a new verb like "allocate", but the WG agreed to remove the
extension of the update.
Okay.
Mirja
>
>
>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
