John Scudder has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: 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
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
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
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
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Finding and
Using Geofeed Data'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action.
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
On Mon, Apr 19, 2021 at 9:59 AM Rob Wilton (rwilton)
wrote:
> Hi Randy,
>
> Thanks for the updates.
>
> Just waiting for confirmation from you/Warren that you are okay with my
> doc status plan and then I'll send it to IETF LC.
>
Yup, completely...
(and apologies for the delay, I've been
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
>>
> ** 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
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;
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-
>
13 matches
Mail list logo
