Sure. > Am 06.08.2018 um 16:53 schrieb Gould, James > <[email protected]>: > > 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
