> On Apr 25, 2017, at 9:47 AM, Acee Lindem (acee) <[email protected]> wrote:
> 
> 
> 
> On 4/25/17, 10:38 AM, "Ben Campbell" <[email protected]> wrote:
> 
>> 
>>> On Apr 25, 2017, at 9:12 AM, Acee Lindem (acee) <[email protected]> wrote:
>>> 
>>> Hi Ben, 
>>> 
>>> On 4/24/17, 10:15 PM, "Ben Campbell" <[email protected]> wrote:
>>> 
>>>> Ben Campbell has entered the following ballot position for
>>>> draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Just a couple of editorial comments:
>>>> 
>>>> -2.2: "This MAY be accomplished by accepting all the keys that have a
>>>> valid accept lifetime and sending the key with the most recent send
>>>> lifetime."
>>>> As written, that MAY sounds like a statement of fact rather than a
>>>> normative requirement. If it's intended as normative, please consider
>>>> restating in terms of actual procedure (e.g. "The receiver MAY accept
>>>> ...")
>>> 
>>> I could either restate it or simply replace the “MAY” with “can”. Since
>>> whether or not graceful key roll-over can be accomplished with
>>> key-chains
>>> has been an area of operator confusion as well as vendors not
>>> implementing
>>> it properly for all applications, I’m going to attempt the former.
>>> 
>>> The receiver MAY accept all the keys that have a valid accept
>>> lifetime and then MAY send the key with the most recent send
>>> lifetime to perform graceful key rollover.
>> 
>> That works for me, except maybe “receiver” doesn’t make as much sense if
>> we are talking about both accepting and sending.
> 
> To achieve graceful key rollover, the receiver MAY accept all
> the keys that have a valid accept lifetime and the sender MAY
> send the key with the most recent send lifetime.

Looks good to me.

> 
> 
>> 
>>> 
>>>> 
>>>> -3, first paragraph: "Is a "key chain key" a key in the keychain, or
>>>> something else? (maybe a key _for_ the keychain)?
>>> 
>>> This is one key from a key chain. In the ietf-key-chain model, we used
>>> to
>>> call these key-entry(s) rather than key(s). However, this was simplified
>>> based on reviews. I believe it was Martin Bjorklund who suggested just
>>> calling them keys. If you read the entire paragraph, I believe the
>>> context
>>> is clear.
>> 
>> From the context, I guessed we were likely talking about a key in the key
>> chain. But I had to stop and think about it. Maybe “member of the
>> keychain”?
> 
> The reason I use “key” is that is what the list data node is referred to
> as. The alternative would be to use “key list element” so it is clear that
> the “Model Design” section is referring to this data node in the model. Of
> course, I think this is clear without this.

Okay, I’m convinced.

Thanks!

Ben.

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to