Re: [regext] Agenda items for IETF97
On Fri, Oct 21, 2016 at 02:56:29PM +, Jody Kolker wrote: > Hi Anton, > > Is there any chance of moving this meeting to a non-Friday slot? Many people > are probably leaving on Friday and would miss this meeting. > The IETF meeting continues through Friday morning, and it always does. The schedule is extremely difficult this time, and requests to move off Friday because people want to go home early will almost certainly be rejected. A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] RDAP lookup queries for reserved or unassignable domains
On Wed, Dec 07, 2016 at 09:56:11AM -0500, John R Levine wrote: > I was thinking that you're the RDAP server for .FOO and someone who's > screwed up his bootstrap asks about BLAH.BAR, with whom you have no > connection. I will just point out that this is the _exact_ reason some of us thought the bootstrap mechanism should have been SRV records in the DNS, because it would have neatly solved that exact problem. > I suppose we could pick another code for "it's not assigned but if you pay > me money it could be" but I really don't think it's a good idea to read > anything beyond "I don't know" into a normal 404 response. I agree with this in principle, but given the way humans actually use the RDDS, there's going to need to be _some_ way to communicate this difference. In particular, for policy reasons it's important to understand "this domain isn't available because someone has it", "this domain isn't available because someone has something that prevents it being registered", and "this domain isn't available to anyone for policy reasons." Consider people doing compliance checks, who maybe shouldn't have access to the SRS directly and who should only have access to the RDDS. They still need to be able to see these distinctions. A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] RDAP lookup queries for reserved or unassignable domains
On Wed, Dec 07, 2016 at 10:20:20AM -0500, Andrew Newton wrote: > > I'm unaware of any HTTP clients that natively use SRV records (there > may be some, but its far from the norm). To me, "neatly" is in the eye > of the beholder. :) I'm similarly unaware of any that know how to look things up in an IANA protocol parameters registry, so I never understood how this was an objection. But anyway, that ship has closed the barn door. A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] RDAP lookup queries for reserved or unassignable domains
On Wed, Dec 07, 2016 at 03:30:24PM +, Gould, James wrote: > It sounds like you’re attempting to morph RDDS into the SRS. Nope. >RDDS is a lookup service and the SRS is an OLTP system. A lookup > service either has the data or it doesn’t. Extra business logic > associated with availability (variant blocking, relationship > blocking, reserved domains, etc.) should be left to the appropriate > channel which is the SRS and not RDDS. Also nope. The idea that the Registration Data Directory Service doesn't have knowledge about the Registration Data such that the repository policies are a secret from the RDDS strikes me as at least unintuitive. Moreover, since one RDDS service (whois) already actually has mechanisms for communicating such information today at least in some implementations, we have running code that we need to conform to. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] RDAP lookup queries for reserved or unassignable domains
On Wed, Dec 07, 2016 at 03:16:01PM -0200, Rubens Kuhl wrote: > > Unintuitive as it is, that was exactly the output of the ICANN EWG on RDDS. Perhaps fortunately, the EWG's output doesn't determine ICANN policy on this. Because the centralised RDS that they were proposing was, IMO, very close to the worst scaling plan I've heard on the Internet in a very long time. > We can do that using a local WHOIS port-43 attender Really? Are we still talking about keeping that miserable obsolete nightmare around even longer? Port 43 must die. A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Multiple REGEXT Sessions at IETF Meetings
On Mon, Jul 31, 2017 at 06:50:28PM +, Roger D Carney wrote: > tings during the week: a working session (90-120 minutes) earlier in the > week and; a status session (90 minutes) later in the week, preferably two or > three days after the working session (e.g. Mon-Wed or Mon-Thur). I rarely make the sessions (I usually have a conflict), but I think you're going to have a very hard time convincing the IESG to give the WG 180 or more minutes. That's a _lot_ of agenda time. I'm also a little sad that a "status" session could take anything approaching 90 minutes. Even the IAB and IESG have figured out that most of what passes for status should not show up in presentations, but should be in emails distributed in advance so that people can discuss topics that arise as a result. Couldn't that be cut down? A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Multiple REGEXT Sessions at IETF Meetings
Ah. That doesn't sound like "status" at all. More like "problem solving". Sounds fabulous. Probably wise to present it to the IESG that way :-) -- Andrew Sullivan Please excuse my clumbsy thums. > On Sep 1, 2017, at 12:25, Andrew Newton wrote: > >> On Mon, Jul 31, 2017 at 2:54 PM, Andrew Sullivan >> wrote: >>> On Mon, Jul 31, 2017 at 06:50:28PM +, Roger D Carney wrote: >>> tings during the week: a working session (90-120 minutes) earlier in the >>> week and; a status session (90 minutes) later in the week, preferably two >>> or three days after the working session (e.g. Mon-Wed or Mon-Thur). >> >> I rarely make the sessions (I usually have a conflict), but I think >> you're going to have a very hard time convincing the IESG to give the >> WG 180 or more minutes. That's a _lot_ of agenda time. >> >> I'm also a little sad that a "status" session could take anything >> approaching 90 minutes. Even the IAB and IESG have figured out that >> most of what passes for status should not show up in presentations, >> but should be in emails distributed in advance so that people can >> discuss topics that arise as a result. Couldn't that be cut down? >> >> A > > I think "status session" doesn't accurately describe what transpired. > It was more like "lightening discussion". Each draft author, sans > slides, gave a two or three sentence "here the issues" statement, and > then mike lines formed with lots of back and forth. I thought it was > quite productive. > > That's my opinion anyway. Maybe others perceived it differently. > > -andy > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Sun, Jan 14, 2018 at 02:31:37PM -0500, John Levine wrote: > > There's little reason to put an ANAME into a TLD zone file. Whatever > you wanted to do with one, you can do equally well with an ANAME at > the apex of a 2LD. Which "you" are we talking about here? There are reasons to put ANAME or DNAME, if you believe those things will work, that have to do with parent-side policy. That can't be done on the child side because then the parent has to monitor all its children, which sucks. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Mon, Jan 15, 2018 at 01:19:09AM -0500, John Levine wrote: > I don't understand the objection. Anyone can put a DNAME at the apex > of a 2LD now, and if we invent ANAMEs, anyone will be able to put > ANAMEs there too. Yes, obviously. > As far as I'm aware, almost no gTLDs or ccTLDs police the contents of > 2LDs now and when they do, it's for content rather than technical > reasons, e.g., to be sure that a sponsored or restricted domain has > the right kind of stuff. Are you anticipating TLDs that will allow > only approved DNAMEs? That seems implausible and unenforcable to me. No, I am anticipating that people want a technical solution to administrative controls that put names into some kind of administrative relationship with one another, such that there are rules about what one may do with one name on the basis of what is done with another name. The usual example of this is the CNNIC policy with respect to IDNs that use simplified or traditional Han characters, but there are other similar examples. Now, I happen to believe that DNAME and ANAME and the proposed-but-so-far-going-nowhere BNAME are all doomed for this purpose, but others don't think that and they want to try (again) to use them. A natural thing to do in that case is to put the relevant records on the parent side of the cut, in order to enforce the policy, instead of monitoring them on the child side. One might argue that what is needed in EPP for that purpose is just the request for the policy feature (the bundling extensions previously up for discussion here), but another way to achieve it is just to provision the relevant RRTYPEs on the parent side. I don't believe that this WG is the correct place to put a "don't do that" filter on these sorts of things. If there is something people want to be able to express in registries, then it's reasonsble to create a standard EPP way to do it. If this WG decides to say, "That's a dumb thing to want, so we won't publish the document," then people will create their own extensions to do those things anyway (since EPP is designed precisely to allow such extensions), and we'll be back to the same problem that brought EPP work back to the IETF: everyone conforms to the standard, and yet there are as many ways to do a thing in EPP as there are registries. That's not desirable. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode
On Fri, Oct 05, 2018 at 02:08:38PM +0200, Niels ten Oever wrote: > We might disagree here. If there is one place in which this extension > might be useful, I am not sure whether standardization is appropriate > because there is only one (potential) implementation. That leads me to > the question: has this actually been implemented in the case of .gov? On the other hand, if people want to standardize some mechanism for a policy you find regrettable, I find it hard to believe that the right answer is "prevent that standard" rather than "don't subject yourself to that policy". The latter is easily achieved by refusing to do business with registries that implement a policy you don't like. The approach that seems to be being pursued here is to try to prevent standardization of the mechanism because of a disagreement about the policy. I think that is generally bad for interoperability. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode
On Fri, Oct 05, 2018 at 03:24:08PM +0200, Niels ten Oever wrote: > We cannot simply wish political implications of our work away. Right, but I don't believe the HRPC work has suggested that things that have HR implications should _not be done_. They should be noted, and I'm all in favour of that. What you are arguing, however, is in line with the way the IETF ended up doing the BEHAVE WG: we wouldn't agree to consider NAT when it was first being worked on, so everyone did it their own way. Then we had 30 million different ways to achieve the same result, none of which worked with anything else, so we had to come up with a bunch of well-defined work arounds to get things to function together. It's not obvious that is an improvement. I think it would be quite good for the document to note that it has the implications you are pointing to, which might be a reason for people not to embrace it. The downsides should be noted. But to me, if I have to weigh "undesirable political implications in an interoperable way, which might draw attention and increase the possibility of implementation" against "undesirable political implications in proprietary ways", I'm going to pick the former every time. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode
On Fri, Oct 05, 2018 at 04:16:04PM +0200, Niels ten Oever wrote: > The difference between NAT and 3rd party verification is that there was > a significant demand for the former, and not for the latter. It seems to me that the WG is a place where a bunch of people who work on registries and registrars get together to talk about things that are useful to them, and you are asserting the non-existence of demand by the non-use of this not yet existing standard. As John points out, there are other possible interpretations open. > Does this mean that the only possible impact of a human rights review > could be recognition in an RFC ? No, but when there are reasonable trade offs among different rights it would be quite inappropriate to attempt to suppress standardization because the review comes down entirely in favour of certain rights. This is _especially_ true in the current case, since the human rights review is not actually part of IETF process but is instead an experiment to see how useful they are. I think the jury is out on that, so far, and efforts like this to suppress standarization efforts on the basis of a preference for certain rights is not that encouraging for the process. This is, after all, a registry protocol. For the land registry in Ontario, I need not only to show up, but actually to show government-issued ID. This is because of fraud that happened in land titles in Ontario some years ago. I trust there is little disagreement with the proposition that fraud involving some domain names has happened. Some registries might attempt to solve that through stronger identification of owner requirements. Whether it would work, I don't know, but that's supposed to be what a competitive market in domain names (and the resulting reputational effects) is supposed to get us. > You seem to be arguing a technological deterministic standpoint here > along the lines of 'everything that is technically possible will happen > anyway, so its better to do it in an interoperable way'. I am not. But we know that there are _current_ things that do some kind of verification in _non_-interoperable ways, and so I fail to see the value in putting fingers in our ears and shouting, "I can't hear you," in response. The IETF is not a human rights advocacy organization, and I do not think it should become one. > By standardizing certain solutions, and not standardizing others, we > change the development and uptake of technologies, especially if > there is not a large demand or an established practice. If there is a demand for a thing that is satisfied by multiple, different established practices, that _too_ is an outcome -- one I think is less desirable for the interoperation of the global Internet. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
