on (rwilton)
> > 发送时间: 2021年4月20日 17:19
> > 收件人: Roman Danyliw ; The IESG
> > 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org;
> draft-ietf-opsawg-tacacs-y...@ietf.org
> > 主题: Re: [OPSAWG] Roman Danyliw's Discuss on
> draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and C
From: Joe Clarke (jclarke)
Sent: 27 April 2021 17:30
On 4/27/21 11:57, tom petch wrote:
> From: OPSAWG on behalf of Joe Clarke (jclarke)
>
> Sent: 27 April 2021 15:48
>
> Thanks, Bo. On your description for the renamed "security" choice, I
> think it is overly descriptive in this case. When a
On 4/27/21 11:57, tom petch wrote:
> From: OPSAWG on behalf of Joe Clarke (jclarke)
>
> Sent: 27 April 2021 15:48
>
> Thanks, Bo. On your description for the renamed "security" choice, I
> think it is overly descriptive in this case. When a new secure T+
> protocol comes out, this future proof
> 发送时间: 2021年4月20日 17:19
> 收件人: Roman Danyliw ; The IESG
> 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org;
> draft-ietf-opsawg-tacacs-y...@ietf.org
> 主题: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10:
> (with DISCUSS and COMMENT)
>
> Hi Roman,
acacs-yang-11
>
>
> Thanks,
> Bo
>
> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Rob Wilton (rwilton)
> 发送时间: 2021年4月20日 17:19
> 收件人: Roman Danyliw ; The IESG
> 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org;
> draft-ietf-opsawg-tacacs-y...@ietf.org
&g
(rwilton)
发送时间: 2021年4月20日 17:19
收件人: Roman Danyliw ; The IESG
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org;
draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10:
(with DISCUSS and COMMENT)
Hi Roman,
Thanks for the review. I
ietf.org; opsawg-cha...@ietf.org; The IESG ; Wubo
>> (lana) ; opsawg@ietf.org
>> Subject: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-
>> yang-10: (with DISCUSS and COMMENT)
>>
>> On 4/20/21 13:36, Alan DeKok wrote:
>>> On Apr 20
g@ietf.org
> Subject: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-
> yang-10: (with DISCUSS and COMMENT)
>
> On 4/20/21 13:36, Alan DeKok wrote:
> > On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke)
> wrote:
> >> Agreed on the point that the cur
On Apr 20, 2021, at 1:56 PM, Joe Clarke (jclarke) wrote:
> ... That is, while
> the "choice" is mandatory, you must make a choice and cannot use both
> shared-secret and whatever else may be added to this choice.
When we did this for RADIUS over TLS, we made the "legacy" RADIUS portion use
a
On Apr 20, 2021, at 1:39 PM, Benjamin Kaduk wrote:
> Reference?
> External PSK is still a thing, and we even published RFC 8773 to expand its
> use cases.
That was my understanding from discussion on EMU about EAP-TLS. If that's
wrong for TLS in general, OK.
I don't think it substantially
On 4/20/21 13:36, Alan DeKok wrote:
> On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) wrote:
>> Agreed on the point that the current payload is obfuscated. The choice
>> element in the YANG module seems to want to be future-proof, too, such
>> that when true encryption is added, it could be au
On Tue, Apr 20, 2021 at 01:36:30PM -0400, Alan DeKok wrote:
>
> On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) wrote:
> > Agreed on the point that the current payload is obfuscated. The choice
> > element in the YANG module seems to want to be future-proof, too, such
> > that when true encry
On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) wrote:
> Agreed on the point that the current payload is obfuscated. The choice
> element in the YANG module seems to want to be future-proof, too, such
> that when true encryption is added, it could be augmented in as another
> choice (instead
On 4/20/21 09:43, Alan DeKok wrote:
> On Apr 20, 2021, at 9:29 AM, Joe Clarke (jclarke)
> wrote:
>>> ** Section 4. choice encryption. Per the name of this YANG item and the
>>> description (“Encryption mechanism between TACACS+ client and server”),
>>> please follow the convention of Section 4
On Apr 20, 2021, at 9:29 AM, Joe Clarke (jclarke)
wrote:
>
>> ** Section 4. choice encryption. Per the name of this YANG item and the
>> description (“Encryption mechanism between TACACS+ client and server”),
>> please follow the convention of Section 4.5 of RFC8907 of calling this
>> “obfus
> ** Section 4. choice encryption. Per the name of this YANG item and the
> description (“Encryption mechanism between TACACS+ client and server”),
> please follow the convention of Section 4.5 of RFC8907 of calling this
> “obfuscation”.
> [Bo]: The reason we define this "encryption" choice is
Hi Roman,
Thanks you for your review. For the discussion part, please see Rob's reply. On
your comment part, please see inline.
-邮件原件-
发件人: Roman Danyliw via Datatracker [mailto:nore...@ietf.org]
发送时间: 2021年4月20日 6:08
收件人: The IESG
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha
Hi Roman,
Thanks for the review. I have chipped in a couple of comments on your discuss
concerns below.
> -Original Message-
> From: iesg On Behalf Of Roman Danyliw via
> Datatracker
> Sent: 19 April 2021 23:08
> To: The IESG
> Cc: opsawg@ietf.org; Joe Clarke (jclarke) ; opsawg-
> c
Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: Discuss
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 ht
19 matches
Mail list logo
