What do we mean by "service"?
Colleagues, What distinguishes our area of work from all others (that I can think of off the top of my head, and some five decades of programming, mostly distributed systems), is that the uniqueness of the identifiers (and we can ignore protocol parameters, which need not necessarily be "numbers", btw), both "names" and "numbers", doesn't take on any particular "uniqueness" meaning until the prefix for any particular name-to-address mappings are announced and can be referenced from "elsewhere". So the instances of communication that concern us are those which the address (actually its prefix) of some device is "announced" (modernly an ASN published via BGP4) and is known, or knowable, to a device at some other address (actually some other prefix), similarly "announced". Where these "announcements" of ASNs and the associated prefixes (via BGP4) are both known is in a table in some intermediate device, which knowing both ASNs is capable of forwarding packets from one ASN to another, with each ASN undertaking the "last hop" or "default" local routing to each of the two devices conducting some instance of communication. We refer to these intermediate ASN-knowing devices as "routers", and those which "take a full (routing) table" (a) have a _lot_ of memory (see Note infra) and (b) form a system which, because announcements and withdrawals of prior announcements occur (mostly) asynchronously, is modernly best thought of as forming the "skitter core" (kudus to kc claffy and CAIDA for the original research and the circular diagrams (some found on the halls of ICANN during its Admiralty Way days)). Back in the EGP period we could think of an "internet core" as existing in some deterministic sense. Modernly, what the global routing table looks like depends on where we are looking from, and our notions of "global routing tables" are statistical in nature. Those of you coming from all important names side of the business may be slightly discomforted by the notion that names don't matter until they are routed, and routed through the Default Free Zone (DFZ), but that's what we really mean when we speak about "globally unique identifiers" -- not the maximal string spaces that can be formed by 63 bytes, nor all the IPv4 and IPv6 addresses, nor all possible parameters the IANA has been tasked to publish, but only those addresses who's prefixes are announced to the DFZ, and those strings associated with those addresses by some names registry. So just as Signaling System 7 (defined by the ITU-T's Q.700-series recommendations) is what we really mean when we say "telephone", that is, a device capable of using the Public Switched Telecommunications Network allowing us to dial-in to a CCWG call and communicate with one another, resolution of a name across the DFZ by two (or more) devices is what we really mean when we, wearing our {ICANN|*NSO|ASO|*AC|DNSOP} policy hats, say "service" (smile optional). This multiply interrupted modest tutorial for some of the people I know can be battered into a para, perhaps even a sentence, with clear meaning, as an alternative to the existing "service" and the alternate "e.g., email, ..." language of the current drafts, and it can be discarded as correct but not useful, or incorrect _and_ not useful. It may assist the final word smiths. Eric Brunner-Wiliams Eugene, Oregon Note: As of 10/09/15 179,957 ASNs were announced in the ARIN region, another 143,717 ASNs were announced in the APNIC region, and another 136,435 ASNs were announced in the RIPE region, another 60,747 ASNs were announced in the LACNIC region, and another 11,914 ASNs were announced in the AfriNIC region.
Eric, Thank you. This is quite helpful in elucidating what we mean when talk about "services which use the Internet's unique identifiers." Greg On Fri, Nov 13, 2015 at 4:59 PM, Eric Brunner-Williams < ebw@abenaki.wabanaki.net> wrote:
Colleagues,
What distinguishes our area of work from all others (that I can think of off the top of my head, and some five decades of programming, mostly distributed systems), is that the uniqueness of the identifiers (and we can ignore protocol parameters, which need not necessarily be "numbers", btw), both "names" and "numbers", doesn't take on any particular "uniqueness" meaning until the prefix for any particular name-to-address mappings are announced and can be referenced from "elsewhere".
So the instances of communication that concern us are those which the address (actually its prefix) of some device is "announced" (modernly an ASN published via BGP4) and is known, or knowable, to a device at some other address (actually some other prefix), similarly "announced".
Where these "announcements" of ASNs and the associated prefixes (via BGP4) are both known is in a table in some intermediate device, which knowing both ASNs is capable of forwarding packets from one ASN to another, with each ASN undertaking the "last hop" or "default" local routing to each of the two devices conducting some instance of communication.
We refer to these intermediate ASN-knowing devices as "routers", and those which "take a full (routing) table" (a) have a _lot_ of memory (see Note infra) and (b) form a system which, because announcements and withdrawals of prior announcements occur (mostly) asynchronously, is modernly best thought of as forming the "skitter core" (kudus to kc claffy and CAIDA for the original research and the circular diagrams (some found on the halls of ICANN during its Admiralty Way days)).
Back in the EGP period we could think of an "internet core" as existing in some deterministic sense. Modernly, what the global routing table looks like depends on where we are looking from, and our notions of "global routing tables" are statistical in nature.
Those of you coming from all important names side of the business may be slightly discomforted by the notion that names don't matter until they are routed, and routed through the Default Free Zone (DFZ), but that's what we really mean when we speak about "globally unique identifiers" -- not the maximal string spaces that can be formed by 63 bytes, nor all the IPv4 and IPv6 addresses, nor all possible parameters the IANA has been tasked to publish, but only those addresses who's prefixes are announced to the DFZ, and those strings associated with those addresses by some names registry.
So just as Signaling System 7 (defined by the ITU-T's Q.700-series recommendations) is what we really mean when we say "telephone", that is, a device capable of using the Public Switched Telecommunications Network allowing us to dial-in to a CCWG call and communicate with one another, resolution of a name across the DFZ by two (or more) devices is what we really mean when we, wearing our {ICANN|*NSO|ASO|*AC|DNSOP} policy hats, say "service" (smile optional).
This multiply interrupted modest tutorial for some of the people I know can be battered into a para, perhaps even a sentence, with clear meaning, as an alternative to the existing "service" and the alternate "e.g., email, ..." language of the current drafts, and it can be discarded as correct but not useful, or incorrect _and_ not useful. It may assist the final word smiths.
Eric Brunner-Wiliams Eugene, Oregon
Note: As of 10/09/15 179,957 ASNs were announced in the ARIN region, another 143,717 ASNs were announced in the APNIC region, and another 136,435 ASNs were announced in the RIPE region, another 60,747 ASNs were announced in the LACNIC region, and another 11,914 ASNs were announced in the AfriNIC region. _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
+1 very informative. Sent from my iPhone On Nov 13, 2015, at 8:24 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: Eric, Thank you. This is quite helpful in elucidating what we mean when talk about "services which use the Internet's unique identifiers." Greg On Fri, Nov 13, 2015 at 4:59 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net<mailto:ebw@abenaki.wabanaki.net>> wrote: Colleagues, What distinguishes our area of work from all others (that I can think of off the top of my head, and some five decades of programming, mostly distributed systems), is that the uniqueness of the identifiers (and we can ignore protocol parameters, which need not necessarily be "numbers", btw), both "names" and "numbers", doesn't take on any particular "uniqueness" meaning until the prefix for any particular name-to-address mappings are announced and can be referenced from "elsewhere". So the instances of communication that concern us are those which the address (actually its prefix) of some device is "announced" (modernly an ASN published via BGP4) and is known, or knowable, to a device at some other address (actually some other prefix), similarly "announced". Where these "announcements" of ASNs and the associated prefixes (via BGP4) are both known is in a table in some intermediate device, which knowing both ASNs is capable of forwarding packets from one ASN to another, with each ASN undertaking the "last hop" or "default" local routing to each of the two devices conducting some instance of communication. We refer to these intermediate ASN-knowing devices as "routers", and those which "take a full (routing) table" (a) have a _lot_ of memory (see Note infra) and (b) form a system which, because announcements and withdrawals of prior announcements occur (mostly) asynchronously, is modernly best thought of as forming the "skitter core" (kudus to kc claffy and CAIDA for the original research and the circular diagrams (some found on the halls of ICANN during its Admiralty Way days)). Back in the EGP period we could think of an "internet core" as existing in some deterministic sense. Modernly, what the global routing table looks like depends on where we are looking from, and our notions of "global routing tables" are statistical in nature. Those of you coming from all important names side of the business may be slightly discomforted by the notion that names don't matter until they are routed, and routed through the Default Free Zone (DFZ), but that's what we really mean when we speak about "globally unique identifiers" -- not the maximal string spaces that can be formed by 63 bytes, nor all the IPv4 and IPv6 addresses, nor all possible parameters the IANA has been tasked to publish, but only those addresses who's prefixes are announced to the DFZ, and those strings associated with those addresses by some names registry. So just as Signaling System 7 (defined by the ITU-T's Q.700-series recommendations) is what we really mean when we say "telephone", that is, a device capable of using the Public Switched Telecommunications Network allowing us to dial-in to a CCWG call and communicate with one another, resolution of a name across the DFZ by two (or more) devices is what we really mean when we, wearing our {ICANN|*NSO|ASO|*AC|DNSOP} policy hats, say "service" (smile optional). This multiply interrupted modest tutorial for some of the people I know can be battered into a para, perhaps even a sentence, with clear meaning, as an alternative to the existing "service" and the alternate "e.g., email, ..." language of the current drafts, and it can be discarded as correct but not useful, or incorrect _and_ not useful. It may assist the final word smiths. Eric Brunner-Wiliams Eugene, Oregon Note: As of 10/09/15 179,957 ASNs were announced in the ARIN region, another 143,717 ASNs were announced in the APNIC region, and another 136,435 ASNs were announced in the RIPE region, another 60,747 ASNs were announced in the LACNIC region, and another 11,914 ASNs were announced in the AfriNIC region. _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
This is indeed informative as a tutorial but I don't see how it helps at all in our endeavor. Indeed, "resolution of a name across the DFZ by two (or more) devices is what we really mean when we, wearing our {ICANN|*NSO|ASO|*AC|DNSOP} policy hats, say "service"" is something that happens to both DNS services that are legitimately regulated by ICANN and ones that are not, and the point of this definitional exercise is to distinguish between the two. I still don't understand what was wrong with my modification of Greg's language. --MM From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Drazek, Keith Sent: Friday, November 13, 2015 5:34 PM To: Greg Shatan <gregshatanipc@gmail.com> Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] What do we mean by "service"? +1 very informative. Sent from my iPhone On Nov 13, 2015, at 8:24 PM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: Eric, Thank you. This is quite helpful in elucidating what we mean when talk about "services which use the Internet's unique identifiers." Greg On Fri, Nov 13, 2015 at 4:59 PM, Eric Brunner-Williams <ebw@abenaki.wabanaki.net<mailto:ebw@abenaki.wabanaki.net>> wrote: Colleagues, What distinguishes our area of work from all others (that I can think of off the top of my head, and some five decades of programming, mostly distributed systems), is that the uniqueness of the identifiers (and we can ignore protocol parameters, which need not necessarily be "numbers", btw), both "names" and "numbers", doesn't take on any particular "uniqueness" meaning until the prefix for any particular name-to-address mappings are announced and can be referenced from "elsewhere". So the instances of communication that concern us are those which the address (actually its prefix) of some device is "announced" (modernly an ASN published via BGP4) and is known, or knowable, to a device at some other address (actually some other prefix), similarly "announced". Where these "announcements" of ASNs and the associated prefixes (via BGP4) are both known is in a table in some intermediate device, which knowing both ASNs is capable of forwarding packets from one ASN to another, with each ASN undertaking the "last hop" or "default" local routing to each of the two devices conducting some instance of communication. We refer to these intermediate ASN-knowing devices as "routers", and those which "take a full (routing) table" (a) have a _lot_ of memory (see Note infra) and (b) form a system which, because announcements and withdrawals of prior announcements occur (mostly) asynchronously, is modernly best thought of as forming the "skitter core" (kudus to kc claffy and CAIDA for the original research and the circular diagrams (some found on the halls of ICANN during its Admiralty Way days)). Back in the EGP period we could think of an "internet core" as existing in some deterministic sense. Modernly, what the global routing table looks like depends on where we are looking from, and our notions of "global routing tables" are statistical in nature. Those of you coming from all important names side of the business may be slightly discomforted by the notion that names don't matter until they are routed, and routed through the Default Free Zone (DFZ), but that's what we really mean when we speak about "globally unique identifiers" -- not the maximal string spaces that can be formed by 63 bytes, nor all the IPv4 and IPv6 addresses, nor all possible parameters the IANA has been tasked to publish, but only those addresses who's prefixes are announced to the DFZ, and those strings associated with those addresses by some names registry. So just as Signaling System 7 (defined by the ITU-T's Q.700-series recommendations) is what we really mean when we say "telephone", that is, a device capable of using the Public Switched Telecommunications Network allowing us to dial-in to a CCWG call and communicate with one another, resolution of a name across the DFZ by two (or more) devices is what we really mean when we, wearing our {ICANN|*NSO|ASO|*AC|DNSOP} policy hats, say "service" (smile optional). This multiply interrupted modest tutorial for some of the people I know can be battered into a para, perhaps even a sentence, with clear meaning, as an alternative to the existing "service" and the alternate "e.g., email, ..." language of the current drafts, and it can be discarded as correct but not useful, or incorrect _and_ not useful. It may assist the final word smiths. Eric Brunner-Wiliams Eugene, Oregon Note: As of 10/09/15 179,957 ASNs were announced in the ARIN region, another 143,717 ASNs were announced in the APNIC region, and another 136,435 ASNs were announced in the RIPE region, another 60,747 ASNs were announced in the LACNIC region, and another 11,914 ASNs were announced in the AfriNIC region. _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Fri, Nov 13, 2015 at 01:59:11PM -0800, Eric Brunner-Williams wrote:
What distinguishes our area of work from all others (that I can think of off the top of my head, and some five decades of programming, mostly distributed systems), is that the uniqueness of the identifiers (and we can ignore protocol parameters, which need not necessarily be "numbers", btw), both "names" and "numbers", doesn't take on any particular "uniqueness" meaning until the prefix for any particular name-to-address mappings are announced and can be referenced from "elsewhere".
I agree with this and the rest of your message; but as I tried to point out in the meeting the other day, for our purposes I don't think the distinction you're making matters. We're trying to say that ICANN isn't allowed to regulate services on the Internet. You're pointing out that some services aren't on the Internet. If we define "services" in this case so that it includes "on the Internet" and "not on the Internet", then ICANN is not allowed to regulate services on the Internet or not on the Internet. This achieves our goal ("on the Internet" being a subset) and has the additional benefit that ICANN can't regulate other things either (not that anyone seemed to suggest they could). But I could well be overlooking something. Is there a reason you want to make the distinction that's relevant to the task at hand? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
participants (5)
-
Andrew Sullivan -
Drazek, Keith -
Eric Brunner-Williams -
Greg Shatan -
Mueller, Milton L