[OPSAWG] RFC 8907 on The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
A new Request for Comments is now available in online RFC libraries. RFC 8907 Title: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol Author: T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant Status: Informational Stream: IETF Date: September 2020 Mailbox:thorstend...@google.com, and...@ota.si, dcmg...@cisco.com, car...@ipsec.org, lol.gr...@gmail.com Pages: 41 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsawg-tacacs-18.txt URL:https://www.rfc-editor.org/info/rfc8907 DOI:10.17487/RFC8907 This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
(Keeping CC list, so I’ll probably reach people and not lists.)
> On 2020-09-28, at 22:41, Guy Harris wrote:
>
> There are tools to convert Markdown to v2 or v3 RFC XML:
>
> https://www.rfc-editor.org/pubprocess/tools/
This is a list of very, very different tools. Some of these are useful for a
“conversion” (as a one-time effort), some are meant to be used in a publishing
pipeline where people rarely see the “object file” that happens to be in XML
(e.g., mmark and kramdown-rfc).
> so:
>
> 1) is it easier to edit Markdown or RFC XML?
I wrote kramdown-rfc a decade ago when I had two days to write six drafts.
I gambled that spending one day on the tool and one day on writing markdown
would be quicker than spending two days on writing XML.
I won.
This was meant as a personal tool to get work done (and, boy, did it speed up
my work), but it has found some other users; approximately 20 % of all
Internet-Drafts are currently being written in kramdown-rfc (approximately 2 %
use mmark).
> 2) is Markdown rich enough to do everything we want to do?
No. So there are some additions.
> For 2), I note that
>
>
> https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md
>
> has a bunch of stuff that GitHub isn't treating as markup, such as the stuff
> prior to the "Introduction" heading, and the tags such as "{::boilerplate
> bcp14}". Is that an extension of Markdown not supported by GitHub's Markdown
> renderer but supported by some Markdown-to-RFC XML converter,
Yes.
(I have since sent Michael an automatically upconverted markdown version of the
XML, BTW.)
> In addition, the XML version at
>
>
> https://github.com/pcapng/pcapng/blob/master/reference-draft-tuexen-opsawg-pcapng.xml
>
> has some additional Decryption Secrets Block secret formats. Those have data
> formats that *themselves* call for figures, and I'd been trying, at one
> point, to determine how to do that in RFC XML v2 format - it might require v3
> format. Can that be handled with Markdown?
You can always fall back to XML inside the markdown, but that is rarely needed.
As an example for a slightly automated form of writing, RFC 7400 was written in
markdown, with a significant part of the text generated automatically from a
Makefile; this text is then included using the {::include …} construct of
kramdown-rfc.
Some resources:
http://rfc.space
http://slides.rfc.space
https://www.ietf.org/mailman/listinfo/rfc-markdown
Grüße, Carsten
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
> On 30. Sep 2020, at 04:14, Qin Wu wrote: > > Hi, two Michaels: > Can you clarify what functionalities is missed for more modern applications? > Since it is enhancement to libpcap, do you expect all the The file format is extensible and allows to include packets from multiple interfaces not having the same physical layer. I can also contain information not related to a particular packet like how many packets where dropped between two packets, how many packets where dropped on which interface during capturing, which capture filters where used, ... I guess this kind of information could be added to the abstract of the document. > future packet capture tools support the format defined in this draft? For Wireshark it is the default. Best regards Michael > > -Qin > -邮件原件- > 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Michael Richardson > 发送时间: 2020年9月29日 4:31 > 收件人: Michael Tuexen ; pcap-ng-for...@winpcap.org; > opsawg@ietf.org; Jasper Bongertz ; > tcpdump-work...@lists.tcpdump.org; Fulvio Risso ; Guy > Harris ; Gerald Combs > 主题: Re: [OPSAWG] New Version Notification for > draft-tuexen-opsawg-pcapng-02.txt > > > Michael Tuexen wrote: >>> internet-dra...@ietf.org wrote: Diff: https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02 >>> >>> Hi, I have converted the xml to markdown. > >> Why? If we want to publish this, it will be published in xmlv3. So >> better to use that format earlier... > > It's so so so much easier to maintain and update and get contributions. > github will render it directly > > If you object strongly, we can stick to XML. > >>> The results in the diff are okay, but actually the conversion is not >>> complete as I cheated and left the tables as preformatted figures, and >>> there are many internal references that I have no yet updated. >>> >>> The xml file had a long list of URLs as references, many of which were >>> duplicated. I will be going through and fixing those in the next week >>> or so. >>> >>> This work has been discussed on and off in OPSAWG, but at this point I >>> am going to suggest that the document just go through the Independant >>> Submission Editor. > >> Do we want to finally publish that? Up to now, I think the point was to >> find a home where it is substantially discussed and improved... > > If we can get OPSAWG to adopt it, great. > I'm just not holding my breath. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > smime.p7s Description: S/MIME cryptographic signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
On Sep 29, 2020, at 7:14 PM, Qin Wu wrote: > Can you clarify what functionalities is missed for more modern applications? > Since it is enhancement to libpcap, do you expect all the future packet > capture tools support the format defined in this draft? pcapng is a file format that's a replacement for pcap. The current version of libpcap can read some pcapng files, but it only shows what can be shown through the existing pcap API, so most of the enhancements don't make a difference to programs using libpcap. That version of libpcap cannot *write* pcapng files. macOS's version of libpcap has undocumented APIs that allow macOS's tcpdump to read and write pcapng files. Wireshark doesn't use libpcap to read capture files; it fully supports reading and writing pcapng files. In the future, we would like to add new APIs to libpcap that support reading and writing pcapng files (and pcap files as well); the new APIs will make all of the added capabilities of pcapng available. However, programs that use libpcap will have to be changed to use the new APIs in order to use those added capabilities. tcpdump will probably be the first program updated to use them. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
On Sep 28, 2020, at 12:06 PM, Michael Tuexen wrote:
> On 28. Sep 2020, at 20:26, Michael Richardson wrote:
>
>> internet-dra...@ietf.org wrote:
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
>>
>> Hi, I have converted the xml to markdown.
>
> Why? If we want to publish this, it will be published in xmlv3. So
> better to use that format earlier...
There are tools to convert Markdown to v2 or v3 RFC XML:
https://www.rfc-editor.org/pubprocess/tools/
so:
1) is it easier to edit Markdown or RFC XML?
2) is Markdown rich enough to do everything we want to do?
For 2), I note that
https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.md
has a bunch of stuff that GitHub isn't treating as markup, such as the stuff
prior to the "Introduction" heading, and the tags such as "{::boilerplate
bcp14}". Is that an extension of Markdown not supported by GitHub's Markdown
renderer but supported by some Markdown-to-RFC XML converter, or incomplete
parts of the RFC XML to Markdown conversion?
In addition, the XML version at
https://github.com/pcapng/pcapng/blob/master/reference-draft-tuexen-opsawg-pcapng.xml
has some additional Decryption Secrets Block secret formats. Those have data
formats that *themselves* call for figures, and I'd been trying, at one point,
to determine how to do that in RFC XML v2 format - it might require v3 format.
Can that be handled with Markdown?
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [tcpdump-workers] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt
On Sep 28, 2020, at 1:42 PM, Michael Tuexen wrote: > Shouldn't we write up (I can work on an initial version) of > a specification for .pcap. https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-gharris-opsawg-pcap.xml=html/ascii=ascii ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IPR Poll for draft-opsawg-ntf
I am not aware of any IPR (responding as contributor). Thanks --- Alex On 9/23/2020 8:41 PM, Pedro Martinez-Julia wrote: > Dear Tianran, > > I am one of the authors of the document and I am not aware of any IPR > that applies to it. > > Regards, > Pedro > > On Thu, Sep 24, 2020 at 02:58:51AM +, Tianran Zhou wrote: >> Hi Authors, >> >> >> >> Accompany with the WG LC, this mail starts the IPR poll. >> >> >> >> Are you aware of any IPR that applies to draft-opsawg-ntf-04? >> >> >> >> If you own or are aware of any IPR that applies to draft-opsawg-ntf-04, >> please clarify whether this IPR been disclosed in compliance with IETF IPR >> rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> >> >> If you are listed as a document author or contributor please respond to this >> email in OPSAWG mailing list regardless of whether or not you are aware of >> any relevant IPR. The document will not advance to the next stage until a >> response has been received from each author and contributor. >> >> >> >> If you are not listed as an author or contributor but are on OPSAWG mailing >> list, then please explicitly respond if you are aware of any IPR that has >> not yet been disclosed in conformance with IETF rules. >> >> >> >> Thanks, >> >> Tianran ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
