Hi, so I posted -08 of pcaplinktype in an attempt to correct the HTML, but
that didn't work. I upgraded to xml2rfc 3.25 locally, and I get mixed results.
I asked online, and was told that there are CSS issues with the HTML produced
on the DT, and I've filed a bug report. The TXT file (and XML) a
> Some minor proposed changes can be found at:
>
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/compare/master...boucadair:draft-ietf-opsawg-pcap:patch-3.
Merged.
> For the various url ref entries with "n,d", may be better to set "date:
false".
okay, I'll do that.
My und
On Nov 26, 2024, at 8:40 AM, Michael Richardson wrote:
> Hi, so I posted -08 of pcaplinktype in an attempt to correct the HTML, but
> that didn't work. I upgraded to xml2rfc 3.25 locally, and I get mixed
> results.
> I asked online, and was told that there are CSS issues with the HTML produced
LGTM
On Wed, Nov 27, 2024, at 10:47, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you
> review the proposed registration in draft-ietf-opsawg-teas-common-ac-13
> for us? Please see
>
> https://data
Dear Tim Bray, Martin Thomson (cc: opsawg WG),
As the designated experts for the IETF XML Registry registry, can you review
the proposed registration in draft-ietf-opsawg-teas-attachment-circuit-18 for
us? Please see
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
T
Dear Tim Bray, Martin Thomson (cc: opsawg WG),
As the designated experts for the IETF XML Registry registry, can you review
the proposed registration in draft-ietf-opsawg-ntw-attachment-circuit-14 for
us? Please see
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
The
LGTM
On Wed, Nov 27, 2024, at 10:39, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you
> review the proposed registration in
> draft-ietf-opsawg-ntw-attachment-circuit-14 for us? Please see
>
> http
LGTM
On Wed, Nov 27, 2024, at 10:42, David Dong via RT wrote:
> Dear Tim Bray, Martin Thomson (cc: opsawg WG),
>
> As the designated experts for the IETF XML Registry registry, can you
> review the proposed registration in
> draft-ietf-opsawg-teas-attachment-circuit-18 for us? Please see
>
> htt
Dear Tim Bray, Martin Thomson (cc: opsawg WG),
As the designated experts for the IETF XML Registry registry, can you review
the proposed registration in draft-ietf-opsawg-teas-common-ac-13 for us? Please
see
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
The due date is Dec
Hello Med,
yes, TLS keylog is a very powerful and dangerous tool and needs to be used
with care. Where I thought it would be primarily be used is a test or
staging environment where configurations are built, updated and tested
before brought to production. If a tool, such as Wireshark, is used to
On Nov 26, 2024, at 1:28 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Heikki,
> I have one comment about the suggestion to indicate that
> draft-ietf-tls-keylogfile is a better option.
> That spec says actually the following:
> This format is intended for use in
>systems where TLS onl
Hi Heikki,
Thanks.
Having an **informative** reference to SSLKEYLOGFILE with a **caution**
pointing to the applicability scope seems OK to me.
Cheers,
Med
De : Heikki Vatiainen
Envoyé : mardi 26 novembre 2024 11:52
À : BOUCADAIR Mohamed INNOV/NET
Cc : opsawg
Objet : Re: [OPSAWG]draft-ietf-o
I’m glad this was brought up, and I agree mentioning this with a scope
precaution seems wise as an operational consideration in migrating to the
secure protocol.
Joe
From: mohamed.boucad...@orange.com
Date: Tuesday, November 26, 2024 at 07:24
To: Heikki Vatiainen
Cc: opsawg
Subject: [OPSAWG]
Hi Alan,
I'm afraid that we need to handle this globally (e.g., in UTA WG), not for
every application.
For example, BCP 195 says:
Nevertheless, this
document does not discourage software from implementing NULL
cipher suites, since they can be useful for testing and debugging
On Nov 26, 2024, at 7:27 AM, mohamed.boucad...@orange.com wrote:
> I'm afraid that we need to handle this globally (e.g., in UTA WG), not for
> every application.
I agree.
I spoke with Eric Vyncke in Dublin, and explained that while RFC 9325 is
good, RADIUS and TACACS+ were having similar i
Re-,
Sounds like a plan :-)
When that work is started, I'd recommend you set it under:
https://www.rfc-editor.org/info/bcp195.
For the specific tacacs+ case, citing BCP195 instead of RFC 9325 would allow us
to inherit these guidelines in the future.
Thank you.
Cheers,
Med
> -Message d'
Hi Doug, all,
I remember that the draft was updated to refer to BCP195 per a comment from
Valery
(https://mailarchive.ietf.org/arch/msg/opsawg/U3mPq3WlRF48blMmr2uCF80KLiI/),
however I see that there some very few places to udpate:
OLD:
RFC9325 offers substantial guidance for implementing pr
Thanks Med, good catch, we’ll add this to the next version (16)
From: mohamed.boucad...@orange.com
Date: Tuesday, 26 November 2024 at 13:05
To: draft-ietf-opsawg-tacacs-tl...@ietf.org
Cc: opsawg
Subject: BCP 195 RE: [OPSAWG]Re: draft-ietf-opsawg-tacacs-tls13: Debugging
TACACS+ over TLS
Hi Dou
18 matches
Mail list logo
