Re: who runs the root, Cogent-TATA peering dispute?
It appears that Bryan Fields said: >Suppose the community wanted to change this or make a formal policy on root >server hosting requirements. Where would this be done? Could a party submit >a proposal to ICANN via the policy development process? If not where should >the community start this? The Governance Working Group that David mentioned has been grinding along for the better part of a decade. It's quite a difficult problem. The existing roots are doing a decent job, and any more formal arrangement runs the risk of politically motivated "improvements". People are worried about what happens if a root goes rogue or disappears but unless the rogue operator were Verisign, which is utterly implausible, the result would be not much. These days a lot of web caches have their own copies of the root that they get directly from ICANN or Verisign. (See RFC 8806. It's really easy.) For everyone else, most clients now make DNSSEC queries and the root's signatures expire after two weeks. I would be a lot more worried about the other scenario David hinted at, a future iteration of the US government tells ICANN or Verisign to do something to the root zone, e.g., delete Iran or Russia or point their name servers at something else. https://community.icann.org/pages/viewpage.action?pageId=120820189 R's, John
Re: who runs the root, Cogent-TATA peering dispute?
Oops. Missed a (significant) word. On May 19, 2024, at 3:02 PM, David Conrad via NANOG wrote: > On May 19, 2024, at 1:12 PM, Bryan Fields wrote: >> Suppose the community wanted to change this or make a formal policy on root >> server hosting requirements. Where would this be done? Could a party submit >> a proposal to ICANN via the policy development process? If not where should >> the community start this? > > That’s exactly what the Root Server System Governance Working Group > (https://community.icann.org/pages/viewpage.action?pageId=120820189) is > trying to figure out. As John has noted, it has been going on for 6+ years > now. See RSSAC-037 > (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and > RSSAC-058 > (https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf). In > the past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) > and the root server operators have made various commitments related to > “service expectations” documented in ICANN's RSSAC document series > (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf), > but as has been pointed out, those commitments are contractual or otherwise > binding obligations. “… are NOT contractual or otherwise binding obligations.” Regards, -drc signature.asc Description: OpenPGP digital signature
Re: who runs the root, Cogent-TATA peering dispute?
On May 19, 2024, at 1:12 PM, Bryan Fields wrote: > Suppose the community wanted to change this or make a formal policy on root > server hosting requirements. Where would this be done? Could a party submit > a proposal to ICANN via the policy development process? If not where should > the community start this? That’s exactly what the Root Server System Governance Working Group (https://community.icann.org/pages/viewpage.action?pageId=120820189) is trying to figure out. As John has noted, it has been going on for 6+ years now. See RSSAC-037 (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and RSSAC-058 (https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf). In the past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) and the root server operators have made various commitments related to “service expectations” documented in ICANN's RSSAC document series (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf), but as has been pointed out, those commitments are contractual or otherwise binding obligations. Regards, -drc signature.asc Description: OpenPGP digital signature
Re: who runs the root, Cogent-TATA peering dispute?
On 5/19/24 3:13 PM, David Conrad via NANOG wrote: > When you say “ICANN” who, exactly, do you mean? ICANN the organization or > ICANN the community? If the former, ICANN Org can’t do anything outside of > ICANN community defined policy or process or risk all sorts of > unpleasantness from internal policies to lawsuits to the ICANN Board being > spilled. If you mean the latter, ICANN org must abide by the ICANN > community’s demands or you get to the same point as previously mentioned. > That’s the whole point behind the “Empowered Community." Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this? Please note, I'm not taking a position, only asking where the community needs to start. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: who runs the root, Cogent-TATA peering dispute?
John, On May 19, 2024, at 12:53 PM, John R. Levine wrote: > On Sun, 19 May 2024, David Conrad wrote: >>> They provide this to Verisign, the Root Zone Maintainer, who create the >>> root zone and distribute it to the root server operators. >> >> Technically, IANA provides database change requests to Verisign. The actual >> database is maintained by the Root Zone Maintainer (hence the name). > > Good point. > > In any event, I think we agree that none of IANA, ICANN, and/or Verisign > has the authority to remove one of the root operators, no matter how much > someone might dislike their peering policies. Yes. While technically, there is the capability (they are, after all merely entries in a database that get dumped into a file), the question of authority (ignoring court order) is less clear cut and certainly does not reside in ICANN org, PTI, or Verisign. Regards, -drc signature.asc Description: OpenPGP digital signature
Re: who runs the root, Cogent-TATA peering dispute?
On Sun, 19 May 2024, David Conrad wrote: They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators. Technically, IANA provides database change requests to Verisign. The actual database is maintained by the Root Zone Maintainer (hence the name). Good point. In any event, I think we agree that none of IANA, ICANN, and/or Verisign has the authority to remove one of the root operators, no matter how much someone might dislike their peering policies. R's, John PS: Perhaps the GWG will eventually come up with a way to do that but I'm not holding my breath. It's been six years since RSSAC 037 and 038. I can't blame them for moving very slowly since it would be all too easy to come up with something worse than the current non-system
Re: who runs the root, Cogent-TATA peering dispute?
John, On May 17, 2024, at 6:53 PM, John R. Levine wrote: > ICANN as the IANA Functions Operator maintains the database of TLD info. Sort of. > They provide this to Verisign, the Root Zone Maintainer, who create the > root zone and distribute it to the root server operators. Technically, IANA provides database change requests to Verisign. The actual database is maintained by the Root Zone Maintainer (hence the name). > Verisign does > this under a contract with NTIA, one of the few bits of the Internet that > is still under a US government contract: > > https://www.ntia.gov/page/verisign-cooperative-agreement Err, no. You forgot the little bit about the IANA Functions transition. Specifically: https://www.icann.org/en/stewardship-implementation/root-zone-maintainer-agreement-rzma > Should ICANN attempt to mess with the distribution of the root zone, let > us just say that the results would not be pretty. There's a balance of > terror here. ICANN carefully never does anything that would make the root > server operators say no, and the root server operators carefully avoid > putting ICANN in a position where they might have to do that. When you say “ICANN” who, exactly, do you mean? ICANN the organization or ICANN the community? If the former, ICANN Org can’t do anything outside of ICANN community defined policy or process or risk all sorts of unpleasantness from internal policies to lawsuits to the ICANN Board being spilled. If you mean the latter, ICANN org must abide by the ICANN community’s demands or you get to the same point as previously mentioned. That’s the whole point behind the “Empowered Community." > I'm not guessing here, I go to ICANN meetings and talk to these people. And I was one of the ICANN people involved in the negotiations with Verisign on the RZMA. Regards, -drc signature.asc Description: OpenPGP digital signature
Re: who runs the root, Cogent-TATA peering dispute?
On Fri, May 17, 2024 at 6:53 PM John R. Levine wrote: > On Fri, 17 May 2024, William Herrin wrote: > > That said, ICANN generates the root zone including the servers > > declared authoritative for the zone. > > Nope. Verisign maintains them under contract to ICANN and NTIA and under direction from ICANN. If ICANN told Verisign to make a change they really didn't want to make, Verisign has just enough wiggle room to delay until the NTIA rep can weigh in. Generally, though, ICANN administers, Verisign implements and NTIA funds the effort. > > So they do have an ability to > > say: nope, you've crossed the line to any of the root operators. > > ICANN as the IANA Functions Operator maintains the database of TLD info. > They provide this to Verisign, the Root Zone Maintainer, who create the > root zone and distribute it to the root server operators. Verisign does > this under a contract with NTIA, one of the few bits of the Internet that > is still under a US government contract: > > https://www.ntia.gov/page/verisign-cooperative-agreement This contract is also a part of the story: https://www.icann.org/iana_imp_docs/129-root-zone-maintainer-service-agreement-v-28sep16 Absent interdiction from NTIA it gives ICANN the authority to direct Verisign to do exactly what I said. And Cogent disconnecting the C servers from a sizable part of the Internet is almost certainly sufficient excuse to do it on an "emergency" basis without soliciting comment. > Should ICANN attempt to mess with the distribution of the root zone, let > us just say that the results would not be pretty. Fair. Whether they could, politically, make it stick is a whole other can of worms. > I'm not guessing here, I go to ICANN meetings and talk to these people. And you've been around since the early days too, but the documents don't always match the talk. The talk reflects intentions. Intentions change faster than contracts when something puts pressure on the system. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: who runs the root, Cogent-TATA peering dispute?
> On May 18, 2024, at 03:53, John R. Levine wrote: > On Fri, 17 May 2024, William Herrin wrote: >> That said, ICANN generates the root zone including the servers >> declared authoritative for the zone. > Nope. > >> So they do have an ability to >> say: nope, you've crossed the line to any of the root operators. > Very very nope. > > ICANN as the IANA Functions Operator maintains the database of TLD info. They > provide this to Verisign, the Root Zone Maintainer, who create the root zone > and distribute it to the root server operators. Verisign does this under a > contract with NTIA, one of the few bits of the Internet that is still under a > US government contract: > > https://www.ntia.gov/page/verisign-cooperative-agreement > > Should ICANN attempt to mess with the distribution of the root zone, let us > just say that the results would not be pretty. There's a balance of terror > here. ICANN carefully never does anything that would make the root server > operators say no, and the root server operators carefully avoid putting ICANN > in a position where they might have to do that. John is exactly correct on each of these points. And I guess I’d go a little further and say that ICANN and IANA are separate entities, with IANA predating ICANN by a decade. -Bill
Re: who runs the root, Cogent-TATA peering dispute?
On Fri, 17 May 2024, William Herrin wrote: That said, ICANN generates the root zone including the servers declared authoritative for the zone. Nope. So they do have an ability to say: nope, you've crossed the line to any of the root operators. Very very nope. ICANN as the IANA Functions Operator maintains the database of TLD info. They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators. Verisign does this under a contract with NTIA, one of the few bits of the Internet that is still under a US government contract: https://www.ntia.gov/page/verisign-cooperative-agreement Should ICANN attempt to mess with the distribution of the root zone, let us just say that the results would not be pretty. There's a balance of terror here. ICANN carefully never does anything that would make the root server operators say no, and the root server operators carefully avoid putting ICANN in a position where they might have to do that. I'm not guessing here, I go to ICANN meetings and talk to these people. R's, John
