Indeed.
The more important action though would be to tell IANA...
/js
On Thu, Dec 01, 2022 at 04:01:30PM -0800, Randy Presuhn wrote:
> Hi -
>
> There *is* an issue - the first two possible values spelled out
> in the DESCRIPTION clause do not match the enumerated SYNTAX
> values' labels.
>
>
Hi -
There *is* an issue - the first two possible values spelled out
in the DESCRIPTION clause do not match the enumerated SYNTAX
values' labels.
Randy
On 2022-12-01 1:46 PM, Chris Smiley wrote:
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
On Nov 30,
> From: Alan DeKok
> On Dec 1, 2022, at 1:14 PM, Marc Huber wrote:
> We're just going through this with RADIUS. We defined RADIUS over TLS 10
> years ago, and left the MD5 obfuscation in.
>
> We're now updating it to remove MD5. In hindsight, it was a mistake.
> Among other things,
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
> On Nov 30, 2022, at 6:26 PM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7666,
> "Management Information Base for Virtual Machines Controlled by a Hypervisor".
>
>
Thu, Dec 01, 2022 at 06:00:53PM +, Joe Clarke (jclarke):
> I’ve read the -01 revision, and the new text in Section 4 seems logical to
> me. Being a bit pedantic, it might be good to reference that section when
> deciding on the correct ERROR to send.
No problem; that will be in the next
On Dec 1, 2022, at 1:14 PM, Marc Huber wrote:
> I've the gut feeling that
>
>Peers MUST NOT use Obfuscation with TLS.
> ...
> isn't the best approach. This would break the transition process
> compatibility for devices that don't encrypt on their own which move TLS to
> an intermediate
Hi,
I've the gut feeling that
Peers MUST NOT use Obfuscation with TLS.
A TACACS+ client initiating a TACACS+ TLS connection MUST set the
TAC_PLUS_UNENCRYPTED_FLAG bit, thereby asserting that Obfuscation is
not used for the Session. All subsequent packets MUST have the
I’ve read the -01 revision, and the new text in Section 4 seems logical to me.
Being a bit pedantic, it might be good to reference that section when deciding
on the correct ERROR to send.
Joe
From: OPSAWG on behalf of heasley
Date: Thursday, December 1, 2022 at 00:32
To: opsawg@ietf.org
[JMC] It makes sense conceptually. In practice, though, it seems very
inefficient for the NAS to be resolving the user-group assignments at the
packet level (the draft mentions something to this effect). You’re right that
resolving that at the controller level wouldn’t be any more practical.
Dear OPSAWG，
I support the WGLC for this document and believe it’s an important extension to
IPFIX to address the emerging SRv6 use case. Thanks!
Haoyu
From: OPSAWG mailto:opsawg-boun...@ietf.org>> On
Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To:
Hi, Joe,
[JMC] It makes sense conceptually. In practice, though, it seems very
inefficient for the NAS to be resolving the user-group assignments at the
packet level (the draft mentions something to this effect). You're right that
resolving that at the controller level wouldn't be any more
Hello everyone,
I’m not aware of any IPR that appplies to this draft.
Best regards,
Pierre.
> On 1 Dec 2022, at 09:07, Alex Huang Feng wrote:
>
> Dear OPSAWG,
>
> No, I’m not aware of any IPR that applies to this draft.
>
> Regards,
> Alex
>
>> On 30 Nov 2022, at 14:55, Joe Clarke
Dear OPSAWG,
No, I’m not aware of any IPR that applies to this draft.
Regards,
Alex
> On 30 Nov 2022, at 14:55, Joe Clarke (jclarke)
> wrote:
>
> Authors and contributors, please respond on-list as to whether or not you are
> aware of any IPR that pertains to this work.
>
> Please state
13 matches
Mail list logo
