From merike at doubleshotsecurity.com Wed Jun 7 18:53:23 2017 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 7 Jun 2017 11:53:23 -0700 Subject: [dnstap] creating infromational RFC Message-ID: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> Hi all. At the DNS-OARC meeting in Madrid a few weeks ago there was a BoF to discuss next steps and overall user and developer cohesivess regarding dnstap. I asked everyone to join the list so that this list could be used for all discussions. It was decided that we should write an Informational RFC to document current dnstap capabilities and I offered to shepherd the editing of this document. If you are interested in being a co-author, please send me a note (or reply to this list). I spoke with Matt Poundsett at NANOG 2 days ago and he kindly sent me info on markdown so I wouldn?t have to revert to ?vi? and hand-edit html (yes, I used to edit some rfcs that way) and has offered to create the initial template. THANK YOU!! The -00 draft submission cutoff is July 3, 2017 so there is a time component associated with this. I hope to get the co-authors sorted by end of this week and get some work started early next week. Thanks all. - merike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From edmonds at mycre.ws Wed Jun 7 19:33:25 2017 From: edmonds at mycre.ws (Robert Edmonds) Date: Wed, 7 Jun 2017 15:33:25 -0400 Subject: [dnstap] creating infromational RFC In-Reply-To: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> Message-ID: <20170607193325.mn6vivzmxjaztce7@mycre.ws> Merike Kaeo wrote: > It was decided that we should write an Informational RFC to document current dnstap capabilities and I offered to shepherd the editing of this document. If you are interested in being a co-author, please send me a note (or reply to this list). I spoke with Matt Poundsett at NANOG 2 days ago and he kindly sent me info on markdown so I wouldn?t have to revert to ?vi? and hand-edit html (yes, I used to edit some rfcs that way) and has offered to create the initial template. THANK YOU!! Before we get started on an I-D, I think it would be prudent to get an answer to whether an RFC (even an informational RFC) can specify something that depends on an unspecified wire encoding like Protocol Buffers 2. E.g., there are plenty of RFCs that specify an XML format and cite a non-IETF standard (XML is apparently under W3C change control), so it's no problem to write an I-D that depends on another standards organization's spec. But TTBOMK there's no actual specification for the PB2 wire format. The simplest thing to do would be to find an RFC that specifies something in terms of Protocol Buffers and use that as precedent, I guess. BTW, the closest thing to a PB2 wire format spec is the expired I-D https://datatracker.ietf.org/doc/draft-rfernando-protocol-buffers/. -- Robert Edmonds From jerry at dns-oarc.net Thu Jun 8 06:08:03 2017 From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=) Date: Thu, 8 Jun 2017 06:08:03 +0000 Subject: [dnstap] creating infromational RFC In-Reply-To: <20170607193325.mn6vivzmxjaztce7@mycre.ws> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> <20170607193325.mn6vivzmxjaztce7@mycre.ws> Message-ID: <5f780579-a48e-39cc-e868-48ba5306802b@dns-oarc.net> On 06/07/17 19:33, Robert Edmonds wrote: > Before we get started on an I-D, I think it would be prudent to get an > answer to whether an RFC (even an informational RFC) can specify > something that depends on an unspecified wire encoding like Protocol > Buffers 2. > > E.g., there are plenty of RFCs that specify an XML format and cite a > non-IETF standard (XML is apparently under W3C change control), so it's > no problem to write an I-D that depends on another standards > organization's spec. But TTBOMK there's no actual specification for the > PB2 wire format. > > The simplest thing to do would be to find an RFC that specifies > something in terms of Protocol Buffers and use that as precedent, I > guess. If your looking at moving to something other then Protocol Buffer I would say use CBOR (RFC 7049) and either use a schema or register a tag. CBOR is more or less a standardized MessagePack and it is equal to Protocol Buffers. Or maybe the RFC should describe the data structure and not how it is "packed" or transported? Cheers, Jerry From shane at time-travellers.org Fri Jun 9 09:34:36 2017 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 9 Jun 2017 09:34:36 +0000 Subject: [dnstap] creating infromational RFC In-Reply-To: <20170607193325.mn6vivzmxjaztce7@mycre.ws> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> <20170607193325.mn6vivzmxjaztce7@mycre.ws> Message-ID: <20170609093436.04fdcf4b@earth.zonnestelsel.tk> Robert, At 2017-06-07 15:33:25 -0400 Robert Edmonds wrote: > Merike Kaeo wrote: > > It was decided that we should write an Informational RFC to > > document current dnstap capabilities and I offered to shepherd the > > editing of this document. If you are interested in being a > > co-author, please send me a note (or reply to this list). I spoke > > with Matt Poundsett at NANOG 2 days ago and he kindly sent me info > > on markdown so I wouldn?t have to revert to ?vi? and hand-edit html > > (yes, I used to edit some rfcs that way) and has offered to create > > the initial template. THANK YOU!! > > Before we get started on an I-D, I think it would be prudent to get an > answer to whether an RFC (even an informational RFC) can specify > something that depends on an unspecified wire encoding like Protocol > Buffers 2. The IETF's kung-fu would have to be pretty weak if we can't make an informational RFC that refers to a format not standardized officially anywhere. :) Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digitale handtekening URL: From merike at doubleshotsecurity.com Fri Jun 9 14:38:47 2017 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Fri, 9 Jun 2017 07:38:47 -0700 Subject: [dnstap] creating infromational RFC In-Reply-To: <20170609093436.04fdcf4b@earth.zonnestelsel.tk> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> <20170607193325.mn6vivzmxjaztce7@mycre.ws> <20170609093436.04fdcf4b@earth.zonnestelsel.tk> Message-ID: > On Jun 9, 2017, at 2:34 AM, Shane Kerr wrote: > > Robert, > > At 2017-06-07 15:33:25 -0400 > Robert Edmonds wrote: > >> Merike Kaeo wrote: >>> It was decided that we should write an Informational RFC to >>> document current dnstap capabilities and I offered to shepherd the >>> editing of this document. If you are interested in being a >>> co-author, please send me a note (or reply to this list). I spoke >>> with Matt Poundsett at NANOG 2 days ago and he kindly sent me info >>> on markdown so I wouldn?t have to revert to ?vi? and hand-edit html >>> (yes, I used to edit some rfcs that way) and has offered to create >>> the initial template. THANK YOU!! >> >> Before we get started on an I-D, I think it would be prudent to get an >> answer to whether an RFC (even an informational RFC) can specify >> something that depends on an unspecified wire encoding like Protocol >> Buffers 2. > > The IETF's kung-fu would have to be pretty weak if we can't make an > informational RFC that refers to a format not standardized officially > anywhere. :) I think we are good but I did want to check with a few folks at IETF for due diligence. Dayjob has been busy so will be getting to this over the weekend. Also, have had some folks send me email unicast who wanted to contribute. More in a few days. - merike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From edmonds at mycre.ws Fri Jun 9 17:06:33 2017 From: edmonds at mycre.ws (Robert Edmonds) Date: Fri, 9 Jun 2017 13:06:33 -0400 Subject: [dnstap] creating infromational RFC In-Reply-To: <5f780579-a48e-39cc-e868-48ba5306802b@dns-oarc.net> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> <20170607193325.mn6vivzmxjaztce7@mycre.ws> <5f780579-a48e-39cc-e868-48ba5306802b@dns-oarc.net> Message-ID: <20170609170633.uyrdb3pb4rpxzo4f@mycre.ws> Jerry Lundstr?m wrote: > If your looking at moving to something other then Protocol Buffer I > would say use CBOR (RFC 7049) and either use a schema or register a tag. > CBOR is more or less a standardized MessagePack and it is equal to > Protocol Buffers. Hi, Jerry: I think CBOR is the prime candidate if a dnstap v2 were to be developed, but my impression from the DNS-OARC meeting is folks are interested in specifying the existing protocol (dnstap v1), which uses protobufs, because the existing protocol is what implementations are using. > Or maybe the RFC should describe the data structure and not how it is > "packed" or transported? I do think it is worth specifying the dnstap data model and serialization profiles separately. Otherwise the spec wouldn't be much more than a .proto file with comments. The transport protocol that is typically used for dnstap (https://github.com/farsightsec/fstrm is the reference implementation) has nothing in it that's dnstap specific. It could benefit from being formally specified but I don't see why it would need to be specified in the same document as dnstap proper. -- Robert Edmonds From jerry at dns-oarc.net Mon Jun 12 06:30:21 2017 From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=) Date: Mon, 12 Jun 2017 06:30:21 +0000 Subject: [dnstap] creating infromational RFC In-Reply-To: <20170609170633.uyrdb3pb4rpxzo4f@mycre.ws> References: <3DBB8DF5-A22E-49DA-A9EA-8092579280D2@doubleshotsecurity.com> <20170607193325.mn6vivzmxjaztce7@mycre.ws> <5f780579-a48e-39cc-e868-48ba5306802b@dns-oarc.net> <20170609170633.uyrdb3pb4rpxzo4f@mycre.ws> Message-ID: Hi Robert, On 06/09/17 17:06, Robert Edmonds wrote: > I do think it is worth specifying the dnstap data model and > serialization profiles separately. Otherwise the spec wouldn't be much > more than a .proto file with comments. +1 The informational RFC can describe the reference implementation that exists in protobuf but looking at the data model it can easily be described in CBOR, JSON, XML, YAML... well, whatever really and you do not need to wait for v2. Something that v2 of DNSTAP could do is to extend the data model to describe the DNS message deeper then just the wire-format. Cheers, Jerry