Subject: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Apr 2017 19:15:40 -0700

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
...")

-3, first paragraph: "Is a "key chain key" a key in the keychain, or
something else? (maybe a key _for_ the keychain)?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 25 Apr 2017 14:12:00 +0000

Hi Ben, 

>https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/

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.

>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.  

Thanks,
Acee

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Apr 2017 09:38:06 -0500

> On Apr 25, 2017, at 9:12 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Ben, 
> 

That works for me, except maybe “receiver” doesn’t make as much sense if we are talking about both accepting and sending.

> calling them keys. If you read the entire paragraph, I believe the context

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”?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 25 Apr 2017 14:47:32 +0000

On 4/25/17, 10:38 AM, "Ben Campbell" <[email-masked]> wrote:

>>> Please refer to
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>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.

>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.

Thanks,
Acee

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Apr 2017 09:53:24 -0500

> On Apr 25, 2017, at 9:47 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Looks good to me.

> course, I think this is clear without this.

Okay, I’m convinced.

Thanks!

Ben.