Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-26 Thread Warren Kumari 
[ + Paul Hoffman for real this time! ]

On Mon, Nov 26, 2018 at 8:43 PM Warren Kumari  wrote:

>
>
> On Wed, Nov 21, 2018 at 1:27 PM Heather Flanagan 
> wrote:
>
>>
>> On 11/21/18 9:33 AM, Warren Kumari wrote:
>>
>> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ]
>>
>> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 21 Nov 2018, at 14:42, Alexey Melnikov 
>>> wrote:
>>>
>>>
>>> Thanks for the quick response.
>>>
>>>
>>> Hi Sara,
>>>
>>>
>>> 1)
>>>
>>> In 7.4.2:
>>>
>>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>   |  |   |   | input. |
>>>
>>> This makes the [pcap] reference Normative. If you don't want to do that,
>>> please
>>> fully specify syntax in this document.
>>>
>>>
>>> Is that true if it is an optional field?
>>>
>>> Yes, optionallity of a field doesn't make its full specification
>>> optional.
>>>
>>>
>>> In which case it seems we can either include a more specific normative
>>> reference here to this page:
>>> http://www.tcpdump.org/manpages/pcap-filter.7.html
>>>
>>> or reproduce this page in an appendix. I’d prefer the former unless a
>>> reference to such a web page would prove problematic as a normative
>>> reference?
>>>
>>
>> We discussed this on the telechat, and I took the action to try look into
>> this.
>> One of the concerns with a normative reference to the webpage is what
>> happens if it is updated to add a new primitive - is it allowed? If someone
>> implements this on Thursday, can they still claim conformance if a new
>> primitive is added on Friday?
>>
>>
>> If there was a way to point to a particular snapshot of the page (e.g., a
>> particular hash on a GitHub page, a particular timestamped version) that
>> would get around this.
>>
>
> Actually, there is - the tcpdump man pages (and actually all of their
> documentation!) lives in github - the version that this document references
> is:
>
> https://raw.githubusercontent.com/the-tcpdump-group/tcpdump-htdocs/7785b0d834e1f77a1d2ec56c96f51f4bf3bf3de2/manpages/pcap-filter.7.txt
>
>
>>
>>
>> What we made up on the call was to simply grab a copy of
>> http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under
>> the BSD license) and put it somewhere on ietf.org, so we have a stable
>> snapshot to reference, and ask you to point to that.
>> But, this was simply us making stuff up on the fly - I'm hoping that the
>> RFC Editor can tell us if this is sane or the worst idea ever, or
>> what'''
>>
>>
>> This also works, though I'd want to you all to think about the precedent
>> this sets. Are you willing to do this on a regular basis? Managing a one
>> off, dealing any any particular copyright issues (not a problem in this
>> case, I believe, but it could be interesting in other cases), those are
>> more challenging.
>>
>>
>>
> Paul Hoffman (CCed) noted that we've discussed this before, and has
> (kindly!) offered to write an ID discussing the issue, and proposing the
> above - this would give us some process to follow.
>
> So, I'm proposing that, in this case, the authors update the reference to
> point at the GitHub link, and we discuss the larger issue when Paul
> provides a draft.
> Does that work for:
> a: the RFC Ed
> b: the authors
> and,
> c: Alexey, who is holding a DISCUSS.
> ?
>
> W
>
>
>
>> -Heather
>>
>>
>>
>> W
>>
>>
>>
>>
>>>
>>> Sara.
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad idea
>> in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair of
>> pants.
>>---maf
>>
>>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-26 Thread Warren Kumari 
On Wed, Nov 21, 2018 at 1:27 PM Heather Flanagan  wrote:

>
> On 11/21/18 9:33 AM, Warren Kumari wrote:
>
> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ]
>
> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  wrote:
>
>>
>>
>> On 21 Nov 2018, at 14:42, Alexey Melnikov  wrote:
>>
>>
>> Thanks for the quick response.
>>
>>
>> Hi Sara,
>>
>>
>> 1)
>>
>> In 7.4.2:
>>
>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>   |  |   |   | input. |
>>
>> This makes the [pcap] reference Normative. If you don't want to do that,
>> please
>> fully specify syntax in this document.
>>
>>
>> Is that true if it is an optional field?
>>
>> Yes, optionallity of a field doesn't make its full specification optional.
>>
>>
>> In which case it seems we can either include a more specific normative
>> reference here to this page:
>> http://www.tcpdump.org/manpages/pcap-filter.7.html
>>
>> or reproduce this page in an appendix. I’d prefer the former unless a
>> reference to such a web page would prove problematic as a normative
>> reference?
>>
>
> We discussed this on the telechat, and I took the action to try look into
> this.
> One of the concerns with a normative reference to the webpage is what
> happens if it is updated to add a new primitive - is it allowed? If someone
> implements this on Thursday, can they still claim conformance if a new
> primitive is added on Friday?
>
>
> If there was a way to point to a particular snapshot of the page (e.g., a
> particular hash on a GitHub page, a particular timestamped version) that
> would get around this.
>

Actually, there is - the tcpdump man pages (and actually all of their
documentation!) lives in github - the version that this document references
is:
https://raw.githubusercontent.com/the-tcpdump-group/tcpdump-htdocs/7785b0d834e1f77a1d2ec56c96f51f4bf3bf3de2/manpages/pcap-filter.7.txt


>
>
> What we made up on the call was to simply grab a copy of
> http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under
> the BSD license) and put it somewhere on ietf.org, so we have a stable
> snapshot to reference, and ask you to point to that.
> But, this was simply us making stuff up on the fly - I'm hoping that the
> RFC Editor can tell us if this is sane or the worst idea ever, or
> what'''
>
>
> This also works, though I'd want to you all to think about the precedent
> this sets. Are you willing to do this on a regular basis? Managing a one
> off, dealing any any particular copyright issues (not a problem in this
> case, I believe, but it could be interesting in other cases), those are
> more challenging.
>
>
>
Paul Hoffman (CCed) noted that we've discussed this before, and has
(kindly!) offered to write an ID discussing the issue, and proposing the
above - this would give us some process to follow.

So, I'm proposing that, in this case, the authors update the reference to
point at the GitHub link, and we discuss the larger issue when Paul
provides a draft.
Does that work for:
a: the RFC Ed
b: the authors
and,
c: Alexey, who is holding a DISCUSS.
?

W



> -Heather
>
>
>
> W
>
>
>
>
>>
>> Sara.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-22 Thread Joe Abley 
Hi Heather,

Since I was cc'd: I ran into this the other week in an academic paper, and I 
was surprised that I couldn't find a normative description of the pcap format. 
I'm glad it wasn't just me :-)

I wound up citing the format with reference to a particular version of tcpdump; 
the name of the tool plus a URL citation ("retrieved on") plus a version number 
seemed to me to be sufficient kindness to future archaeologists.

It might be nice in the future if some kind soul took the time to work with the 
tcpdump community to write up a stable description of the pcap format, edited 
for style in the series in which it is published. I don't suggest that being a 
sensible approach for this document, though.


Joe

> On Nov 21, 2018, at 13:27, Heather Flanagan  wrote:
> 
>> On 11/21/18 9:33 AM, Warren Kumari wrote:
>> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ] 
>> 
>>> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  wrote:
>>> 
>>> 
 On 21 Nov 2018, at 14:42, Alexey Melnikov  wrote:
>>> 
>>> Thanks for the quick response.
>>> 
 
 Hi Sara,
>> 
>> 1)
>> 
>> In 7.4.2:
>> 
>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>   |  |   |   | input. |
>> 
>> This makes the [pcap] reference Normative. If you don't want to do that, 
>> please
>> fully specify syntax in this document.
> 
> Is that true if it is an optional field? 
 Yes, optionallity of a field doesn't make its full specification optional.
>>> 
>>> In which case it seems we can either include a more specific normative 
>>> reference here to this page:
>>> http://www.tcpdump.org/manpages/pcap-filter.7.html
>>> 
>>> or reproduce this page in an appendix. I’d prefer the former unless a 
>>> reference to such a web page would prove problematic as a normative 
>>> reference? 
>> 
>> We discussed this on the telechat, and I took the action to try look into 
>> this.
>> One of the concerns with a normative reference to the webpage is what 
>> happens if it is updated to add a new primitive - is it allowed? If someone 
>> implements this on Thursday, can they still claim conformance if a new 
>> primitive is added on Friday?
> 
> If there was a way to point to a particular snapshot of the page (e.g., a 
> particular hash on a GitHub page, a particular timestamped version) that 
> would get around this.
> 
> 
> 
>> 
>> What we made up on the call was to simply grab a copy of 
>> http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under the 
>> BSD license) and put it somewhere on ietf.org, so we have a stable snapshot 
>> to reference, and ask you to point to that.
>> But, this was simply us making stuff up on the fly - I'm hoping that the RFC 
>> Editor can tell us if this is sane or the worst idea ever, or what'''
> 
> This also works, though I'd want to you all to think about the precedent this 
> sets. Are you willing to do this on a regular basis? Managing a one off, 
> dealing any any particular copyright issues (not a problem in this case, I 
> believe, but it could be interesting in other cases), those are more 
> challenging.
> 
> 
> 
> -Heather
> 
> 
> 
>> 
>> W
>> 
>> 
>>  
>>> 
>>> Sara. 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> 
>> -- 
>> I don't think the execution is relevant when it was obviously a bad idea in 
>> the first place.
>> This is like putting rabid weasels in your pants, and later expressing 
>> regret at having chosen those particular rabid weasels and that pair of 
>> pants.
>>---maf
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-21 Thread Heather Flanagan 


On 11/21/18 9:33 AM, Warren Kumari wrote:

[ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ]

On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson > wrote:





On 21 Nov 2018, at 14:42, Alexey Melnikov mailto:aamelni...@fastmail.fm>> wrote:


Thanks for the quick response.



Hi Sara,


1)

In 7.4.2:

  | filter   | O | T | "tcpdump" [pcap] style filter
for  |
  |  |   |   | input.
|

This makes the [pcap] reference Normative. If you don't want to
do that, please
fully specify syntax in this document.


Is that true if it is an optional field?

Yes, optionallity of a field doesn't make its full specification
optional.


In which case it seems we can either include a more specific
normative reference here to this page:
http://www.tcpdump.org/manpages/pcap-filter.7.html

or reproduce this page in an appendix. I’d prefer the former
unless a reference to such a web page would prove problematic as a
normative reference?


We discussed this on the telechat, and I took the action to try look 
into this.
One of the concerns with a normative reference to the webpage is what 
happens if it is updated to add a new primitive - is it allowed? If 
someone implements this on Thursday, can they still claim conformance 
if a new primitive is added on Friday?



If there was a way to point to a particular snapshot of the page (e.g., 
a particular hash on a GitHub page, a particular timestamped version) 
that would get around this.





What we made up on the call was to simply grab a copy of 
http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be 
under the BSD license) and put it somewhere on ietf.org 
, so we have a stable snapshot to reference, and ask 
you to point to that.
But, this was simply us making stuff up on the fly - I'm hoping that 
the RFC Editor can tell us if this is sane or the worst idea ever, or 
what'''



This also works, though I'd want to you all to think about the precedent 
this sets. Are you willing to do this on a regular basis? Managing a one 
off, dealing any any particular copyright issues (not a problem in this 
case, I believe, but it could be interesting in other cases), those are 
more challenging.



-Heather




W



Sara.
___
DNSOP mailing list
DNSOP@ietf.org 
https://www.ietf.org/mailman/listinfo/dnsop



--
I don't think the execution is relevant when it was obviously a bad 
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing 
regret at having chosen those particular rabid weasels and that pair 
of pants.

   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-21 Thread Sara Dickinson 


> On 21 Nov 2018, at 17:33, Warren Kumari  wrote:
> 
> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ] 
> 
> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  > wrote:
> 
> 
>> On 21 Nov 2018, at 14:42, Alexey Melnikov > > wrote:
> 
> Thanks for the quick response.
> 
>> 
>> Hi Sara,
 
 1)
 
 In 7.4.2:
 
   | filter   | O | T | "tcpdump" [pcap] style filter for  |
   |  |   |   | input. |
 
 This makes the [pcap] reference Normative. If you don't want to do that, 
 please
 fully specify syntax in this document.
>>> 
>>> Is that true if it is an optional field? 
>> Yes, optionallity of a field doesn't make its full specification optional.
> 
> In which case it seems we can either include a more specific normative 
> reference here to this page:
> http://www.tcpdump.org/manpages/pcap-filter.7.html 
> 
> 
> or reproduce this page in an appendix. I’d prefer the former unless a 
> reference to such a web page would prove problematic as a normative 
> reference? 
> 
> We discussed this on the telechat, and I took the action to try look into 
> this.
> One of the concerns with a normative reference to the webpage is what happens 
> if it is updated to add a new primitive - is it allowed? If someone 
> implements this on Thursday, can they still claim conformance if a new 
> primitive is added on Friday?
> 
> What we made up on the call was to simply grab a copy of 
> http://www.tcpdump.org/manpages/pcap-filter.7.html 
>  (it seems to be under 
> the BSD license) and put it somewhere on ietf.org , so we 
> have a stable snapshot to reference, and ask you to point to that.
> But, this was simply us making stuff up on the fly - I'm hoping that the RFC 
> Editor can tell us if this is sane or the worst idea ever, or what….

Thanks for the update, we’ll hold off till we hear more on this. 

Sara. ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-21 Thread Warren Kumari 
[ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ]

On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson  wrote:

>
>
> On 21 Nov 2018, at 14:42, Alexey Melnikov  wrote:
>
>
> Thanks for the quick response.
>
>
> Hi Sara,
>
>
> 1)
>
> In 7.4.2:
>
>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>   |  |   |   | input. |
>
> This makes the [pcap] reference Normative. If you don't want to do that,
> please
> fully specify syntax in this document.
>
>
> Is that true if it is an optional field?
>
> Yes, optionallity of a field doesn't make its full specification optional..
>
>
> In which case it seems we can either include a more specific normative
> reference here to this page:
> http://www.tcpdump.org/manpages/pcap-filter.7.html
>
> or reproduce this page in an appendix. I’d prefer the former unless a
> reference to such a web page would prove problematic as a normative
> reference?
>

We discussed this on the telechat, and I took the action to try look into
this.
One of the concerns with a normative reference to the webpage is what
happens if it is updated to add a new primitive - is it allowed? If someone
implements this on Thursday, can they still claim conformance if a new
primitive is added on Friday?

What we made up on the call was to simply grab a copy of
http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under
the BSD license) and put it somewhere on ietf.org, so we have a stable
snapshot to reference, and ask you to point to that.
But, this was simply us making stuff up on the fly - I'm hoping that the
RFC Editor can tell us if this is sane or the worst idea ever, or what

W




>
> Sara.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-21 Thread Sara Dickinson 


> On 21 Nov 2018, at 14:42, Alexey Melnikov  wrote:

Thanks for the quick response.

> 
> Hi Sara,
>>> 
>>> 1)
>>> 
>>> In 7.4.2:
>>> 
>>>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>   |  |   |   | input. |
>>> 
>>> This makes the [pcap] reference Normative. If you don't want to do that, 
>>> please
>>> fully specify syntax in this document.
>> 
>> Is that true if it is an optional field? 
> Yes, optionallity of a field doesn't make its full specification optional.

In which case it seems we can either include a more specific normative 
reference here to this page:
http://www.tcpdump.org/manpages/pcap-filter.7.html 


or reproduce this page in an appendix. I’d prefer the former unless a reference 
to such a web page would prove problematic as a normative reference? 

Sara. ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-21 Thread Sara Dickinson 


> On 19 Nov 2018, at 20:37, Alexey Melnikov  wrote:

Hi Alexey, 

Thanks for the review.

> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: Discuss
> --
> DISCUSS:
> --
> 
> Thank you for this document, it is a useful contribution to RFC series. I
> enjoyed reading it.
> 
> I have a small list of issues that is hopefully easy to fix:
> 
> 1)
> 
> In 7.4.2:
> 
>   | filter   | O | T | "tcpdump" [pcap] style filter for  |
>   |  |   |   | input. |
> 
> This makes the [pcap] reference Normative. If you don't want to do that, 
> please
> fully specify syntax in this document.

Is that true if it is an optional field? 

> 
> 2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due to use 
> of
> CDDL in Appendix A. If you don't think CDDL is normative, you need to state
> that in Appendix A.

Yes indeed - it should be normative, will fix. 


> 
> --
> COMMENT:
> --
> 
> Was CDDL in Appendix A validated with a tool? This information is missing from
> the shepherding write-up.

We (the authors) have used the CDDL tool described on http://cbor.io/tools.html 
 to read the CDDL in Appendix A and ensured an 
example instance can be created. 

Did you have some other validation tool in mind?

> 
> 6.2.3.  Storage flags
> 
>   The Storage Parameters also contains optional fields holding details
>   of the sampling method used and the anonymisation method used.  It is
>   RECOMMENDED these fields contain URIs pointing to resources
>   describing the methods used.
> 
> Please add a Normative Reference for URI spec here (RFC 3986).

Yes, will do. 

> 
> 7.5.3.2.  "QueryResponseSignature"
> 
>   | qr-transport-flags | O | U | Bit flags describing the transport   |
>   ||   |   | used to service the query.   |
>   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
>   ||   |   | IPv6 |
>   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
>   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
>   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
>   ||   |   | reserved for future use. |
>   ||   |   | Bit 5. 1 if trailing bytes in query  |
>   ||   |   | packet. See Section 11.2.|
> 
> Would something like DoH appear as a separate transport choice?

No, we need to add DoH to this list (it didn’t exist when we started the 
draft!). 

> 
> How can new values be added to the list if there are no IANA Considerations?

As described in response to the DISCUSS on this issue we propose IANA create a 
C-DNS registry with
subregistries with keys for each of the different maps used in C-DNS.
New entries in these subregistries would follow Expert Review 

> 
> 7.5.3.5.  "MalformedMessageData"
> 
>   ||   |   |  |
>   | mm-transport-flags | O | U | Bit flags describing the transport   |
>   ||   |   | used to service the query. Bit 0 is  |
>   ||   |   | the least significant bit.   |
>   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
>   ||   |   | IPv6 |
>   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
>   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
>   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
>   ||   |   | reserved for future use. |
> 
> If the above bits supposed to be the same as for qr-transport-flags,
> maybe it is worth defining them once and referencing in all relevant places?

The qr-transport-flags and mm-transport-flags are different in that the 
qr-transport-flags include Bit 5, the trailing bytes indicator.

In the CDDL a base ’TransportFlags’ type is defined and then

mm-transport-flags => TransportFlags,

qr-transport-flags=> QueryResponseTransportFlags,

 QueryResponseTransportFlagValues = &(
  query-trailingdata : 5,
  ) / TransportFlagValues
  QueryResponseTransportFlags = uint .bits QueryResponseTransportFlagValues

We can add some text to the table descriptions in sections 7.5.3.2 and 7.5.3.5 
to clarify the relationship. 

> 
> 7.6.  "QueryResponse"
>   | query-size   | O | U | DNS query message size (see|
>   |  |   |   | below).|
>   |  |   |   |

[DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

2018-11-19 Thread Alexey Melnikov 
Alexey Melnikov has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: Discuss

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.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/



--
DISCUSS:
--

Thank you for this document, it is a useful contribution to RFC series. I
enjoyed reading it.

I have a small list of issues that is hopefully easy to fix:

1)

In 7.4.2:

   | filter   | O | T | "tcpdump" [pcap] style filter for  |
   |  |   |   | input. |

This makes the [pcap] reference Normative. If you don't want to do that, please
fully specify syntax in this document.

2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due to use of
CDDL in Appendix A. If you don't think CDDL is normative, you need to state
that in Appendix A.


--
COMMENT:
--

Was CDDL in Appendix A validated with a tool? This information is missing from
the shepherding write-up.

6.2.3.  Storage flags

   The Storage Parameters also contains optional fields holding details
   of the sampling method used and the anonymisation method used.  It is
   RECOMMENDED these fields contain URIs pointing to resources
   describing the methods used.

Please add a Normative Reference for URI spec here (RFC 3986).

7.5.3.2.  "QueryResponseSignature"

   | qr-transport-flags | O | U | Bit flags describing the transport   |
   ||   |   | used to service the query.   |
   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   ||   |   | IPv6 |
   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
   ||   |   | reserved for future use. |
   ||   |   | Bit 5. 1 if trailing bytes in query  |
   ||   |   | packet. See Section 11.2.|

Would something like DoH appear as a separate transport choice?

How can new values be added to the list if there are no IANA Considerations?

7.5.3.5.  "MalformedMessageData"

   ||   |   |  |
   | mm-transport-flags | O | U | Bit flags describing the transport   |
   ||   |   | used to service the query. Bit 0 is  |
   ||   |   | the least significant bit.   |
   ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   ||   |   | IPv6 |
   ||   |   | Bit 1-4. Transport. 4 bit unsigned   |
   ||   |   | value where 0 = UDP, 1 = TCP, 2 =|
   ||   |   | TLS, 3 = DTLS. Values 4-15 are   |
   ||   |   | reserved for future use. |

If the above bits supposed to be the same as for qr-transport-flags,
maybe it is worth defining them once and referencing in all relevant places?

7.6.  "QueryResponse"
   | query-size   | O | U | DNS query message size (see|
   |  |   |   | below).|
   |  |   |   ||
   | response-size| O | U | DNS query message size (see|
   |  |   |   | below).|

I think "DNS response message size" for response-size.

It is odd to have RFC 2119 language in B.2, which is itself informative.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop