Internet-Draft draft-ietf-opsawg-tacacs-tls13-11.txt is now available. It is a
work item of the Operations and Management Area Working Group (OPSAWG) WG of
the IETF.
Title: Terminal Access Controller Access-Control System Plus (TACACS+)
over TLS 1.3
Authors: Thorsten Dahm
John
Thanks you for your feedback and insights.
We have uploaded a new version to include corrections.
We have deferred ref to RFC9608 at this stage, as we are still checking to
determine if the provisions would be relevant to the TLS cases used for T+
transport.
If we have missed anything or you h
Joe Clarke (jclarke) wrote:
> I agree that pcap is ready to go.
> I'll double check just to be sure.
> [JMC] Give me the all clear, and I’ll run the WG LC in parallel.
I have double checked.
I think that the introduction needs some text explaining that this document
is Historial. T
On Aug 12, 2024, at 5:03 AM, Michael Richardson wrote:
> I wish we set the pcap"ng" version field to "3", following from pcap v2 being
> the last. It could be done perhaps, and pcap"ng" could be version pcap3.
I wish we'd avoided using the string "pcap" in the name of the extensible
capture fi
Michael Richardson wrote:
> Joe Clarke (jclarke) wrote:
>> I agree that pcap is ready to go.
>> I'll double check just to be sure.
>> [JMC] Give me the all clear, and I’ll run the WG LC in parallel.
> I have double checked.
> I think that the introduction needs some tex
Guy Harris wrote:
> On Aug 12, 2024, at 5:03 AM, Michael Richardson
wrote:
>> I wish we set the pcap"ng" version field to "3", following from pcap v2
being
>> the last. It could be done perhaps, and pcap"ng" could be version pcap3.
> I wish we'd avoided using the string "pca
On 8/12/24, 08:36, "Michael Richardson" wrote:
Michael Richardson mailto:mcr+i...@sandelman.ca>> wrote:
> Joe Clarke (jclarke) mailto:jcla...@cisco.com>> wrote:
>> I agree that pcap is ready to go.
>> I'll double check just to be sure.
>> [JMC] Give me the all clear, and I’ll r
Joe Clarke (jclarke) wrote:
> One thing that occurs to me – not to throw a wrench in this – is why
> not make pcap informational (like we did with TACACS+)? I suppose one
> reason to make it historical is if the pcap format is no longer being
> used (as opposed to pcapng).
pcap
Mahesh Jethanandani has entered the following ballot position for
draft-ietf-opsawg-mud-iot-dns-considerations-16: Yes
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.)
P
Hi Michael,
Thanks for addressing Roman’s DISCUSS and COMMENTs. I have put a ballot of YES,
so the document can move ahead.
As a follow-up, I am reviewing the comments provided by others to make sure
they have been addressed. Erik Kline made the following comment, for which I do
not see a dif
Hello, opsawg. After some delay on the part of the chairs, and after some
recent updates from the authors, we are ready to begin a two-week WG LC for
https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ .
The plan with the three adopted PCAP-related docs is to first get this one
pu
As this document moves through WG LC, we want to reconfirm any known IPR
related to this work:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/
If you are an author or named contributor:
Are you aware of any IPR that applies to draft identified above?
Please state either:
"No,
"No, I'm not aware of any IPR that applies to this draft”
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
OPSAWG mailing list -- opsa
On Aug 12, 2024, at 1:29 PM, Joe Clarke (jclarke)
wrote:
> For now, please review this document and provide all feedback on the list.
There are some link-layer types whose description is either:
1) insufficiently detailed, e.g. LINKTYPE_WIHART, which has a description on
the source site for
14 matches
Mail list logo
