Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
I am not sure at this point, but I suspect the objection had to do with section 6.3 of the -02 document that was published before Buenos Aires: https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem-02 Both documents mention 2860, and I don't see anything in particular to disagree with about how the adpkja document references it, or, indeed, how it referenced it in the -02 version. However, the old section 6.3 does remind me of some things I heard people objecting to in BA. On Wed, Sep 21, 2016 at 11:02 PM, Alain Durand wrote: > > > On Sep 21, 2016, at 8:31 PM, George Michaelson wrote: > > > > On the other hand, the longer documents goes further in recognizing > > name processes are really inherently tied to ICANN process more than > > technical merit arguments. This pleases me, because I feel drawn to > > the view the problems are best expressed as "this is done by somebody > > else, in another equity process" > > This is an interesting observation, as one of the comments we have > received many times about the first revisions of draft-adpkja was that the > references to ICANN were not helping. We even took heat for mentioning > 2860... > > I guess this reflects on the multitude of diverging opinions on the > subject. > > Alain. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
> On Sep 21, 2016, at 8:31 PM, George Michaelson wrote: > > On the other hand, the longer documents goes further in recognizing > name processes are really inherently tied to ICANN process more than > technical merit arguments. This pleases me, because I feel drawn to > the view the problems are best expressed as "this is done by somebody > else, in another equity process" This is an interesting observation, as one of the comments we have received many times about the first revisions of draft-adpkja was that the references to ICANN were not helping. We even took heat for mentioning 2860... I guess this reflects on the multitude of diverging opinions on the subject. Alain. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
This is true. I am being overtly indulgent, to assert my view, and assert my view hasn't changed. This is thomist logic. It's not very conducive to consensus because it doesn't converge, it just rebuts. I do this, because I find the views I am seeing appear to imply a consensus around other views, which make huge inferential leaps (for me at least) about loss/damage from being excluded from existing as a TLD. Why do we necessarily reify these beliefs? Whats the technical merit in the argument as it stands? You are a consensus seeker, and I value that. I sense the emerging consensus, and you will note I allowed my draft to expire and have not re-submitted. To address the primary question from the WG chairs, I find very hard. One document is briefer than the other, and despite my own writing style (!) I value brevity immensely. On the other hand, the longer documents goes further in recognizing name processes are really inherently tied to ICANN process more than technical merit arguments. This pleases me, because I feel drawn to the view the problems are best expressed as "this is done by somebody else, in another equity process" I invite other people to consider technical-needs statements from parallel WG and standards authors skeptically. Ask yourself what burden developers would take, if they had to code to a 2LD, and ask yourself what community burden is taken in the wide, if a new TLD is allocated in 6761 to break out of the DNS. The primary problem is how labels express in tools. The omnibox, browser-bar and shell command-level arguments point to gethostbyname() very very early. Maybe, thats the underlying fundamental problem here more than inclusion or exclusion from the DNS? (I have said this before btw, both here and at the microphone) The uber-conversation, what kind of name-to-record mapping we want, is progressing quite nicely. I like Brian Trammell's work. I like Ed's work recording history (although I could diverge from it) and I don't think the problem-space overall is not being thought about. -G On Thu, Sep 22, 2016 at 9:57 AM, Ted Lemon wrote: > The problem with this kind of certainty is that it's not conducive to > reaching consensus. The reality is that there are a broad set of people > with interest in this question, and they have different beliefs and > different motivations. > > That's why it's important to go through the exercise of having those people > say "this is what I see myself losing if (for example) RFC 6761 is > deprecated with no replacement." And then we see who those people are, > what they will do if they don't get what they want, and so on. > > The problem with the way you are coming at it is that you are just one of > those people, and what you lose with your proposed way forward is nothing > you care about, and what you gain is something you care about a great deal. > There are many people in the exact same situation in this discussion, but > with different things that they lose and gain. So we have to all try to > understand each others' perspectives in order to come up with a way forward > that can gain consensus. We can't just start arguing over which way > forward to choose without doing that groundwork first. > > > On Wed, Sep 21, 2016 at 7:30 PM, George Michaelson wrote: >> >> None of these named spaces would "fail" to work as sub-spaces of .ALT >> or .arpa or any other community-led IETF tech community managed label. >> >> You haven't convinced me they innately need to exist as a TLD. The >> sole entrypoint into that model, is a belief in what happens in the >> browser bar and at the shell. >> >> You are the designer of systems of world scale, I do not doubt. But >> you are bringing an assumption to the table: all things of world scale >> do not have to exist at the top of the worldwide name space. >> >> I remain unconvinced. I remain of the belief, that shutting 6761 down >> is wiser than racionation over the problem space, without recognizing >> intractable elements to this problem because its not at root a >> technology problem: its a name problem. We gave that role to somebody >> else. >> >> -G >> >> On Thu, Sep 22, 2016 at 9:15 AM, hellekin wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA512 >> > >> > On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote: >> >> >> >> And I'm still not convinced there is a problem to solve >> >> (unless the real issue is "how to prevent the registration of .gnu and >> >> .bit?") >> >> >> > >> > Even if I supported the SUDN of P2P systems draft mentioning both .gnu >> > and .bit, I see a great deal of difference between them. .gnu (and >> > .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN >> > response from DNS, and use their respective protocols to resolve from >> > the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a >> > special case in our I-D because it proposes an alternate way of DNS >> > resolution, not using a delegated tree, but a blockchain. Wi
Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
The problem with this kind of certainty is that it's not conducive to reaching consensus. The reality is that there are a broad set of people with interest in this question, and they have different beliefs and different motivations. That's why it's important to go through the exercise of having those people say "this is what I see myself losing if (for example) RFC 6761 is deprecated with no replacement." And then we see who those people are, what they will do if they don't get what they want, and so on. The problem with the way you are coming at it is that you are just one of those people, and what you lose with your proposed way forward is nothing you care about, and what you gain is something you care about a great deal. There are many people in the exact same situation in this discussion, but with different things that they lose and gain. So we have to all try to understand each others' perspectives in order to come up with a way forward that can gain consensus. We can't just start arguing over which way forward to choose without doing that groundwork first. On Wed, Sep 21, 2016 at 7:30 PM, George Michaelson wrote: > None of these named spaces would "fail" to work as sub-spaces of .ALT > or .arpa or any other community-led IETF tech community managed label. > > You haven't convinced me they innately need to exist as a TLD. The > sole entrypoint into that model, is a belief in what happens in the > browser bar and at the shell. > > You are the designer of systems of world scale, I do not doubt. But > you are bringing an assumption to the table: all things of world scale > do not have to exist at the top of the worldwide name space. > > I remain unconvinced. I remain of the belief, that shutting 6761 down > is wiser than racionation over the problem space, without recognizing > intractable elements to this problem because its not at root a > technology problem: its a name problem. We gave that role to somebody > else. > > -G > > On Thu, Sep 22, 2016 at 9:15 AM, hellekin wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote: > >> > >> And I'm still not convinced there is a problem to solve > >> (unless the real issue is "how to prevent the registration of .gnu and > >> .bit?") > >> > > > > Even if I supported the SUDN of P2P systems draft mentioning both .gnu > > and .bit, I see a great deal of difference between them. .gnu (and > > .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN > > response from DNS, and use their respective protocols to resolve from > > the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a > > special case in our I-D because it proposes an alternate way of DNS > > resolution, not using a delegated tree, but a blockchain. With regard > > to DNS, .bit is different from the other five, besides the political > > effects of its specific approach (which I think should be able to exist > > anyway, for the sake of Internet End-to-End principle if nothing else.) > > > > None of the problem statement drafts took reference of the Special-Use > > Domain Names of P2P Systems which initiated this years long discussion > > that ended up with: should we revise or replace RFC6761. In my position > > of editor of this draft, I don't really care what happens to RFC6761, > > but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and > > .bit. I don't think any of the proposed problem statement drafts > > mention the perspective of actual P2P networks sharing their experience > > and their existence, and coming to the table with the idea of abiding to > > the IAB rule of a globally unique namespace. > > > > We say: hey, look, we exist, and we want to say that these are not > > transactional names: they bear cultural value. They came from usage and > > the history of the Internet. The DNS should know about them, so that > > people won't ever get into trouble trying to resolve non-existing names, > > or trying to resolve eventually delegated names that will collide with > > existing networks if they keep being ignored by DNS. > > > > I had the time to appreciate the nuances that IETF members can find in > > this seemingly simple approach, and try to generalize the issue: "what > > if others come and do the same? Who's responsible? How to judge of the > > legitimacy of those claims?" Etc. > > > > But what's been going on, from my point of view of volunteer who only > > has one life (that at least we share) and doesn't get paid for this > > work, is choking-by-bureaucracy. People whose profession is to sit on > > IETF WGs can spend their time not solving issues, they still get food on > > the table. And so production of norms is an endless process, and if not > > this one, another. > > > > As I see it, the problem we're trying to address is whether these P2P > > systems warrant some recognition from the Internet Community, is that > > something we want to encourage,
Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
None of these named spaces would "fail" to work as sub-spaces of .ALT or .arpa or any other community-led IETF tech community managed label. You haven't convinced me they innately need to exist as a TLD. The sole entrypoint into that model, is a belief in what happens in the browser bar and at the shell. You are the designer of systems of world scale, I do not doubt. But you are bringing an assumption to the table: all things of world scale do not have to exist at the top of the worldwide name space. I remain unconvinced. I remain of the belief, that shutting 6761 down is wiser than racionation over the problem space, without recognizing intractable elements to this problem because its not at root a technology problem: its a name problem. We gave that role to somebody else. -G On Thu, Sep 22, 2016 at 9:15 AM, hellekin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote: >> >> And I'm still not convinced there is a problem to solve >> (unless the real issue is "how to prevent the registration of .gnu and >> .bit?") >> > > Even if I supported the SUDN of P2P systems draft mentioning both .gnu > and .bit, I see a great deal of difference between them. .gnu (and > .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN > response from DNS, and use their respective protocols to resolve from > the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a > special case in our I-D because it proposes an alternate way of DNS > resolution, not using a delegated tree, but a blockchain. With regard > to DNS, .bit is different from the other five, besides the political > effects of its specific approach (which I think should be able to exist > anyway, for the sake of Internet End-to-End principle if nothing else.) > > None of the problem statement drafts took reference of the Special-Use > Domain Names of P2P Systems which initiated this years long discussion > that ended up with: should we revise or replace RFC6761. In my position > of editor of this draft, I don't really care what happens to RFC6761, > but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and > .bit. I don't think any of the proposed problem statement drafts > mention the perspective of actual P2P networks sharing their experience > and their existence, and coming to the table with the idea of abiding to > the IAB rule of a globally unique namespace. > > We say: hey, look, we exist, and we want to say that these are not > transactional names: they bear cultural value. They came from usage and > the history of the Internet. The DNS should know about them, so that > people won't ever get into trouble trying to resolve non-existing names, > or trying to resolve eventually delegated names that will collide with > existing networks if they keep being ignored by DNS. > > I had the time to appreciate the nuances that IETF members can find in > this seemingly simple approach, and try to generalize the issue: "what > if others come and do the same? Who's responsible? How to judge of the > legitimacy of those claims?" Etc. > > But what's been going on, from my point of view of volunteer who only > has one life (that at least we share) and doesn't get paid for this > work, is choking-by-bureaucracy. People whose profession is to sit on > IETF WGs can spend their time not solving issues, they still get food on > the table. And so production of norms is an endless process, and if not > this one, another. > > As I see it, the problem we're trying to address is whether these P2P > systems warrant some recognition from the Internet Community, is that > something we want to encourage, or is that something that belongs to > "the Deep Web", and we'd better leave that out of the picture? I'm not > talking about .mail, .corp, and .home, that belong to another category > (I like "toxic waste"), or "people trying to circumvent IANA processes", > or "don't want to pay", or "don't want to follow process". We did > follow process, once we realized there was one. And suddenly, after a > decade, everybody realizes there's an RFC6761 that really shouldn't have > become an RFC in the first place, and this process is flawed, and we > don't know how to handle this. But when the Browser Forum comes with a > deadline, consensus is easily achieved in no time, despite the draft is > flawed with idiotic requirements such as "Users are expected to...". > > My take is that none of the proposed statement drafts took care of > situating the debate in its (recent) historical context. The fear of > frictions between IANA and IETF have had more to do with how things > went, than actual ponder of the technical arguments put forth by the > various RFC6761-based drafts. Case by case is not necessarily evil: not > everything can nor should be automated. > > I believe that in the case of the 6 TLDs we asked for, there's little > doubt they make sense technically, historically, a
Re: [DNSOP] moving forward on special use names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/20/2016 08:57 AM, Suzanne Woolf wrote: > > In a real sense the question at hand is a very practical one: > “Which of these documents do you think needs less work?" > Having read both drafts, and from the perspective of "Names resolved * with an agreed non-DNS protocol", I agree with Avri that they can be complementary, and find draft-tldr-sutld-ps-04 to "need less work". This despite my other message which situates the problem space out of these two drafts. Regards, == hk -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJX4xUEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9gckP/AtTeoArzbW/yB9HbfLVE0BI MEAZlaETW22K2axs+h9Xg0Yge0F0vmmUqRZMZ7rF0UegppZra0M5biF2RxAxFN7n 2iw/Jz0xmq+5TjCzc6SoBvOL8DUbFIbl2auD3F/E/zbvaHEZU240xq+PCv7018KB aApWdLH+/dMb3xZwmXunOm4gzxwD3TyZcYTRRnTN+7Y+SGXRdoeoC0h8Qs4QSdle VHofvLvNreCd2sUP41YjsI4Frz9SDtBHaBJds4R/0iUiPTUgOU5+qygRpfPKckVB sp6kq0ZPOxRAC3h46+vCfOoCpJmkTtV7XdDv8plGHNK7XayVmQepdoCJt8IQYDdu Fnt+MhND+h3rihkLzL/Hxpr9cNWybIdiP8szdvHW9Cvt6LD/uH5nLUq9fIDkurS4 ju/CKWsQnHMgrQM5tJfnwXFDERfMpP1rzNrfRQsJVtvF+MNjN3AmCNYFivgQcKyO A5cfreYZ9J/hCaaL+E9wX25GIQY0TKxOwOTuaGgH4+ck1hqbF8+EHjrbQ942J4+2 3ip/aDj6FOhtpEA68FNJGiG+p1zkNp0S/CBHDWMcEozM6qaAErVa64N9B0jqCeWs y5819q47/2RfAa+PaAmQKT5bRLiIxNpjRKJ4jvA/dfLvHE0rn8exeks8gjAC+Rle 81muRwDKNixMboVxalQz =s4YJ -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote: > > And I'm still not convinced there is a problem to solve > (unless the real issue is "how to prevent the registration of .gnu and > .bit?") > Even if I supported the SUDN of P2P systems draft mentioning both .gnu and .bit, I see a great deal of difference between them. .gnu (and .zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN response from DNS, and use their respective protocols to resolve from the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a special case in our I-D because it proposes an alternate way of DNS resolution, not using a delegated tree, but a blockchain. With regard to DNS, .bit is different from the other five, besides the political effects of its specific approach (which I think should be able to exist anyway, for the sake of Internet End-to-End principle if nothing else.) None of the problem statement drafts took reference of the Special-Use Domain Names of P2P Systems which initiated this years long discussion that ended up with: should we revise or replace RFC6761. In my position of editor of this draft, I don't really care what happens to RFC6761, but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and .bit. I don't think any of the proposed problem statement drafts mention the perspective of actual P2P networks sharing their experience and their existence, and coming to the table with the idea of abiding to the IAB rule of a globally unique namespace. We say: hey, look, we exist, and we want to say that these are not transactional names: they bear cultural value. They came from usage and the history of the Internet. The DNS should know about them, so that people won't ever get into trouble trying to resolve non-existing names, or trying to resolve eventually delegated names that will collide with existing networks if they keep being ignored by DNS. I had the time to appreciate the nuances that IETF members can find in this seemingly simple approach, and try to generalize the issue: "what if others come and do the same? Who's responsible? How to judge of the legitimacy of those claims?" Etc. But what's been going on, from my point of view of volunteer who only has one life (that at least we share) and doesn't get paid for this work, is choking-by-bureaucracy. People whose profession is to sit on IETF WGs can spend their time not solving issues, they still get food on the table. And so production of norms is an endless process, and if not this one, another. As I see it, the problem we're trying to address is whether these P2P systems warrant some recognition from the Internet Community, is that something we want to encourage, or is that something that belongs to "the Deep Web", and we'd better leave that out of the picture? I'm not talking about .mail, .corp, and .home, that belong to another category (I like "toxic waste"), or "people trying to circumvent IANA processes", or "don't want to pay", or "don't want to follow process". We did follow process, once we realized there was one. And suddenly, after a decade, everybody realizes there's an RFC6761 that really shouldn't have become an RFC in the first place, and this process is flawed, and we don't know how to handle this. But when the Browser Forum comes with a deadline, consensus is easily achieved in no time, despite the draft is flawed with idiotic requirements such as "Users are expected to...". My take is that none of the proposed statement drafts took care of situating the debate in its (recent) historical context. The fear of frictions between IANA and IETF have had more to do with how things went, than actual ponder of the technical arguments put forth by the various RFC6761-based drafts. Case by case is not necessarily evil: not everything can nor should be automated. I believe that in the case of the 6 TLDs we asked for, there's little doubt they make sense technically, historically, and culturally. That others may take it as 'a way in' and flood the IETF with stupid drafts 'just in case' seems to me the core of the problem, that was mentioned a few times over the years, but didn't make it through the recent drafts. > The rest of this email is about > draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no > and no. > This is a great summary, thank you! == hk -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJX4xScXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0 5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb S/Y6890dyJOa+014KUBdr
Re: [DNSOP] Updated draft-hoffman-dns-in-json
On Sep 21, 2016, at 3:15 PM, George Michaelson wrote: > I really like this document. I particularly like that it explicitly > addresses how the JSON format it uses can represent *malformed* DNS > state, as seen on the wire. This is very important, because some > canonicalize-and-map-the-DNS efforts I've seen have focussed on > well-formed packets, and this one stands out as saying "no, we have to > be able to represent incorrect state, because that exists on the wire, > and we need to show it sometimes" > > It has multiple encoding possibilities for the DNS RR. I'm a little > confused what difference it makes, that you'd want 'all the things' > here. If the argument is 'long crypto hashes are better done as > base64' then why do we have the hex at all? Hex is easier to type for short blobs. > Is that to preserve > bit-field legibility for instance? Or, to encode unintelligible > off-the-wire sequences which present as a valid RR but you can't > decompose into their constituents? Maybe its just a little guidance > when you saw the hex being used? rather than B64. Really, it's just there because some people prefer one way over the other for some fields. > Do you need to be explicit that transform through this JSON would > permit re-emission of the wire content onto a network, and have the > packets function? Is that even a goal? Not a goal. (Particularly for badly-formed DNS responses :-) ) > The streaming reference sort-of > made me think this might be a goal, but it wasn't explicit to me in a > cursory reading. > > I think this is a good document. I think its close to baked for me. Thanks! And thanks to the many folks who have suggested (and will hopefully continue to suggest) changes. It's way better than the -00. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated draft-hoffman-dns-in-json
I really like this document. I particularly like that it explicitly addresses how the JSON format it uses can represent *malformed* DNS state, as seen on the wire. This is very important, because some canonicalize-and-map-the-DNS efforts I've seen have focussed on well-formed packets, and this one stands out as saying "no, we have to be able to represent incorrect state, because that exists on the wire, and we need to show it sometimes" It has multiple encoding possibilities for the DNS RR. I'm a little confused what difference it makes, that you'd want 'all the things' here. If the argument is 'long crypto hashes are better done as base64' then why do we have the hex at all? Is that to preserve bit-field legibility for instance? Or, to encode unintelligible off-the-wire sequences which present as a valid RR but you can't decompose into their constituents? Maybe its just a little guidance when you saw the hex being used? rather than B64. Do you need to be explicit that transform through this JSON would permit re-emission of the wire content onto a network, and have the packets function? Is that even a goal? The streaming reference sort-of made me think this might be a goal, but it wasn't explicit to me in a cursory reading. I think this is a good document. I think its close to baked for me. George On Thu, Sep 22, 2016 at 6:47 AM, Paul Hoffman wrote: > Greetings. Based on the recent discussion on the DNSOP mailing list (noting > again that this is not a WG work item!), I have updated > draft-hoffman-dns-in-json. I still plan to send this to the ISE for > Experimental in about two weeks, and am happy to make more changes before > then (or after, based on the ISE review). > > --Paul Hoffman > >> A new version of I-D, draft-hoffman-dns-in-json-08.txt >> has been successfully submitted by Paul Hoffman and posted to the >> IETF repository. >> >> Name: draft-hoffman-dns-in-json >> Revision: 08 >> Title:Representing DNS Messages in JSON >> Document date:2016-09-21 >> Group:Individual Submission >> Pages:13 >> URL: >> https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-08.txt >> Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ >> Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-json-08 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-08 >> >> Abstract: >> Some applications use DNS messages, or parts of DNS messages, as >> data. For example, a system that captures DNS queries and responses >> might want to be able to easily search those without having to decode >> the messages each time. Another example is a system that puts >> together DNS queries and responses from message parts. This document >> describes a standardized format for DNS message data in JSON. > > ___ > 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] Update on Current Work
As a note to folks trying to follow the state of all the drafts in the WG, please see https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html Wearing my secretary hat, I try to keep it up to date. For example, as Tim and Suzanne put drafts into WG Last Call, I try to update that page immediately with both the fact that a draft in is Last Call and the end date of the Last Call. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Updated draft-hoffman-dns-in-json
Greetings. Based on the recent discussion on the DNSOP mailing list (noting again that this is not a WG work item!), I have updated draft-hoffman-dns-in-json. I still plan to send this to the ISE for Experimental in about two weeks, and am happy to make more changes before then (or after, based on the ISE review). --Paul Hoffman > A new version of I-D, draft-hoffman-dns-in-json-08.txt > has been successfully submitted by Paul Hoffman and posted to the > IETF repository. > > Name: draft-hoffman-dns-in-json > Revision: 08 > Title:Representing DNS Messages in JSON > Document date:2016-09-21 > Group:Individual Submission > Pages:13 > URL: > https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-08.txt > Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ > Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-in-json-08 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-08 > > Abstract: > Some applications use DNS messages, or parts of DNS messages, as > data. For example, a system that captures DNS queries and responses > might want to be able to easily search those without having to decode > the messages each time. Another example is a system that puts > together DNS queries and responses from message parts. This document > describes a standardized format for DNS message data in JSON. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS-in-JSON draft
On 5 Sep 2016, at 23:26, Jerry Lundström wrote: Hi Paul, On 09/05/16 17:40, Paul Hoffman wrote: On 5 Sep 2016, at 1:42, Jerry Lundström wrote: - Non-ASCII octets escaping "\DDD" may lead to broken implementations and/or encoding problem (oh so many printf()'ed JSON implementations out there) Sure, but I'm not sure what to do about this. It's not really a security consideration, and it's not really even about this format: that's true for any application that gets a host name in return to a PTR query, yes? I was more commenting on the fact that it is escaping in a format that already support escaping. The JSON output would be double escaped and implementations would need to unescape it themselves rather then let JSON handle it. Got it. I'l add a new bit to the Security Considerations about double-escaping. - The use of "!" and "*" in object attribute names will make it hard to use in language that can read JSON and give out native objects such as JavaScript. Yeah, I thought about that: it sucks for most programming languages. Would people be happier if I used "B64" and "HEX" for trailers of names instead of "!" and "*"? I guess I'm in control of the naming and can be sure those don't appear at the end of object names. That would be better yes but it also got me thinking, why two different ways of encoding it? Could be simplified by just using base64url (or base64). I think I'll go with B64 and HEX. The reason for two encodings is that hand-editing HEX is definitely easier than Base64, but DNSSEC keys are often expressed as Base64. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS-in-JSON draft
On 5 Sep 2016, at 21:44, Shane Kerr wrote:
First, it seems like it might be nice to have a way to express RDATA
in
DNS presentation format. The document is very clear that no way is
provided for this, but it seems like it would be really, really
useful.
If it useful for a particular application for particular RDATA, that
application could easily specify a format in its profile. If that
catches on, I could update this document with a collection of those.
But
I don't want to start now by specifying the formats I would want
myself.
Hm... I guess I don't see why the DNS-in-JSON draft can't simply say
that the formats are those documented in the RFC for any particular
RTYPE? Each RTYPE has a defined format, right?
Sure, but some of those types don't have definitions of names for the
presentation format, and some of the early ones have less-than-clear
names. Also, for RTYPEs that have multiple parts to the RDATA, what
would it mean to get an answer that had only some of them?
Next, is compressedNAME likely to be useful? I'm not arguing
strongly
against it, but since it involves pointers and those are not going
to
be useful with a JSON object, I don't really see much point.
I doubt they will be that useful, but a receiver might want to know
which names in a message were compressed and which were not. I admit
that it would be clearer for that receiver to just look through the
message or section binary fields.
Maybe it could be a value that describes something like this:
"compressedNAME": { "isCompressed": "yes", "length": 7 }
The "length" would be the compressed length. The uncompressed length
can be found by looking at the name.
Good suggestion!
I don't see any mention of whether things like TYPEname and
CLASSname
are case-sensitive and if they are not which case they should be. My
recommendation would be to make them case-insensitive, although not
every field can be so having to tag each might be a bit much?
Well, this brought up an ugly problem. The name in the IANA registry
for
class 1 is "Internet (IN)". Chaos and Hesiod are similarly bad. I'm
going to change the definition of the class names to be 'String whose
value is "IN", "CH", "HS", or has the format in {{RFC3597}}'. I don't
think I really need to add to TYPEs that the name is case-sensitive,
since it says "from the IANA RR TYPEs registry".
Makes sense. Stupid DNS classes. :)
Can you explicitly say that TYPEs are case-INsensitive then? It might
save some poor coder at some point, since programming languages
generally default to case-sensitive comparisons...
No, but I will say the opposite, which is more deterministic for
receivers.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Update on Current Work
All I wanted to give a quick update to the group on what work I have lined up in our process queue, and to get people start thinking about agenda items for Seoul, which is coming up in the next two months. I will state right now that I've made the decision that we will *not* be allowing any agenda time for the Special Names discussion (Unless, of course there is no other work going on). We should be able to work this out (or not work this out) on the mailing list, and if need be, have a virtual interim on it. We have several drafts that are working toward Working Group Last Call. Currently, the drafts (and the general order) are: # WGLC order * draft-ietf-dnsop-refuse-any * draft-ietf-dnsop-nsec-aggressiveuse * draft-ietf-dnsop-edns-key-tag (I need to double check with the authors) * draft-ietf-dnsop-attrleaf (Dave needs to deliver a new version and perhaps another iteration.) * draft-ietf-dnsop-no-response-issue (We still outstanding issues) # Other drafts * draft-ietf-dnsop-session-signal We had some good initial discussion right before adoption but we should revisit if there is interest. Mainly, I don't want the authors waiting until the document deadline to push changes... * draft-ietf-dnsop-dns-wireformat-http This draft stirred up discussion in other groups, for better or worse. A new mailing list was spun up to discuss the general idea of dns over http: https://www.ietf.org/mailman/listinfo/dnsoverhttp Though my opinions are that this discussion (and possible work) should not interfere too much this draft moving forward. (and all of this precludes the fact I'm not covering the Special Names documents) # New Work We have a few requests to have drafts adopted, and I have not spent any time looking at them. I will do that, and get back to the authors. questions, comments, complaints, etc are welcome thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
