<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">FWIW, I have been an avid reader of Karl's various pieces time out memory. They still make sense. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Quite apart from a global standard, there is one major influence enabling interoperability across all those surfaces mentioned here. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Treaties...and the obligations thereto!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I have come to know two from making a living in a day job.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">To post a letter or parcel from here to there, the UPU Global Postal Model imposes a rule for various pieces of information - CN 23 data, inclusive of personally-identifying info - must be shared electronically between the origin postal authority, the destination postal authority, the carrier and destination customs. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The letter or parcel must await a 'consent to send' (positive acknowledgement!) advised by the destination postal authority to both the origin postal authority and shipper.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The ICAO protocols surrounding movement of Passenger Name Records (PNR) have a similar framework. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">CAS</div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>==============================<br><i><font face="comic sans ms, sans-serif">Carlton A Samuels</font></i><br><font face="comic sans ms, sans-serif"><i>Mobile: 876-818-1799<br><font color="#33CC00">Strategy, Process, Governance, Assessment & Turnaround</font></i></font><br>=============================</div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Dec 2023 at 00:35, Barry Shein via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org">at-large@atlarge-lists.icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I agree with what you're saying but I'd also point out that the global<br>
voice phone network, postal systems, package delivery, various forms<br>
of travel, at least, also had a "one world" goal.<br>
<br>
I can pretty much make a phone call, mail a letter, deliver a package,<br>
to almost anyone one the planet or perhaps with some effort travel<br>
most anywhere. With perhaps the exception of some extremely poor or<br>
draconian authoritative places.<br>
<br>
And in the same period we began to understand the negative aspects of<br>
globalization like nuclear-tipped ICBMs and pollution (particularly<br>
the CO2 responsible for climate change) which also know no political<br>
boundaries tho don't require interoperability with their target other<br>
than the laws of physics.<br>
<br>
So the model was fomenting w/o some "hippie" notion, it was just<br>
(mostly) post-WW2 globalization.<br>
<br>
Perhaps a minor point but it raises the question as to whether this<br>
overall trend is part of some grand plan or is it just an organic<br>
process like the spread of language, music, religion, etc. which may<br>
hit some bumps in the road but is likely to keep rolling along barring<br>
some apocalyptic disaster.<br>
<br>
On December 22, 2023 at 15:45 <a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a> (Karl Auerbach via At-Large) wrote:<br>
> I am concerned about fragmentation of the net, but in ways that seem to be<br>
> divergent than the concerns I usually hear.<br>
> <br>
> Many, probably most, of us Internet grey beards think of "the Internet" in<br>
> terms of the end-to-end principal of IP (v4 or v6) packets moving without much<br>
> hindrance from a source network interface with an global/public IP address to<br>
> another network interface with its own global/public IP address.<br>
> <br>
> I think that world is dead.<br>
> <br>
> NATs put a nail into the end-to-end principle, but a nail that actually helped<br>
> us expand the IPv4 net without too much damage (except to some old protocols,<br>
> such as FTP, that carry IP addresses as data - most modern protocols are<br>
> reasonably amenable to NATs and TCP-concatenating proxies.)<br>
> <br>
> But there is a different way of looking at The Internet that is not based on<br>
> the old packet-based end-to-end principle. That way is to look at The Internet<br>
> as a collection of underlying internets (lower case) of various technologies<br>
> and addressing that are connected together so that favored (there is much<br>
> danger in that word "favored" - I'll get to that in a moment) applications work<br>
> between users.<br>
> <br>
> This is really saying that we have turned the wheel once more in our long<br>
> progression from "networks" (e.g. ARPAnet) to "network of networks" (Postel's<br>
> "Internet") and now a "network of networks of networks" - a world in which<br>
> "end-to-end" refers not to packets but to application inter-operation.<br>
> <br>
> (This idea is the underlying theme of my somewhat long blog item from 2016:<br>
> "Internet: Quo Vadis (Where are you going?" at <a href="https://www.cavebear.com/" rel="noreferrer" target="_blank">https://www.cavebear.com/</a><br>
> cavebear-blog/internet_quo_vadis/ That note envisioned an evolution - one that<br>
> I believe is happening - in which the once unified Internet changes into a<br>
> system of highly protected "islands" [such as a Google island, a Facebook<br>
> island, a China island, various fundamentalist religious islands, etc] that are<br>
> interconnected by guarded, taxed, filtered, and inspected bridges. This is not<br>
> unlike the walled cities of medieval Europe where the gates in the walls were<br>
> used as much for taxation and excluding undesirables and foreigners as they<br>
> were for defense in war.)<br>
> <br>
> I mentioned that there is danger - that danger is that these inter-island<br>
> bridges will be open only to the most popular of applications. To use a modern<br>
> example, this future Internet-of-internets, might allow protocols such as<br>
> Twitter or Facebook but might exclude new ideas such as Activity Pub (used by<br>
> things like Mastodon.) In other words, our notion of "innovation at the edge"<br>
> will not necessary be valid across this global Internet-of-internets.<br>
> <br>
> I have concerns about this future that I see. But those concerns are not<br>
> necessarily fears as much as concessions to the reality that despite our<br>
> protestations, we humans tend to form clumps - tribes, nations, corporations,<br>
> religions - and we seem to like having the means to pull up the drawbridges, in<br>
> full or in part, that connect us with others. In addition, security concerns,<br>
> intellectual property concerns, and the like are pushing in that direction -<br>
> note recent legal developments around the world to impose content restrictions<br>
> or require proof-of-age or proof-of-identity. Or there may be content<br>
> restrictions, for instance music that is still under copyright in the US may be<br>
> in the public domain elsewhere.<br>
> <br>
> The early Internet grew out of the one-world ideas of the hippie culture of the<br>
> late 1960s - I know, I was there. But rather than tearing down borders, the<br>
> Internet is drawing more boundaries and making the old ones more complicated.<br>
> <br>
> --karl--<br>
> <br>
> <br>
> On 12/22/23 1:04 AM, Wolfgang Kleinwächter wrote:<br>
> <br>
> Thanks Karl,<br>
> <br>
> not totally new, but very helpful in the new environment of the 2020s.<br>
> <br>
> Isn´t this a more serious threat to "Internet Fragmentation" than<br>
> govermental efforts to introduce "national sovereignty" (on the application<br>
> layer) into the borderless cyberspace?<br>
> <br>
> And "Happy Holidays"!!<br>
> <br>
> Wolfgang<br>
> <br>
> <br>
> <br>
> Karl Auerbach via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a>> hat am<br>
> 21.12.2023 20:31 CET geschrieben:<br>
> <br>
> <br>
> You make good points.<br>
> <br>
> I have long accepted the concept of competing root systems and have<br>
> suggested various ways in which they could co-exist without causing<br>
> discomfort for users, particularly with regard to collisions between<br>
> divergent versions of the same TLD string. (See my year 1999 note:<br>
> <a href="https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#" rel="noreferrer" target="_blank">https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#</a><br>
> multiple_roots )<br>
> <br>
> As you mention, we most definitely have some strong neo-root (as<br>
> opposed<br>
> to fully distinct competing root) systems, such as Google's 8.8.8.8,<br>
> Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6<br>
> equivalents.) Whether the query streams to these are being data mined<br>
> is unknown to me. However, I doubt that in today's world of<br>
> "shareholder<br>
> value" that commercial companies, particularly those who strongly<br>
> leverage their revenue streams from personal network usage data they<br>
> gather, will long resist the temptation to monetize those query streams<br>
> - indeed I would be surprised if some have not done so already. One<br>
> may<br>
> ask, as I will do here: Why are these for-profit companies spending<br>
> not-inconsequential amounts of money to deploy services that are<br>
> redundant with the legacy root system? We would be naive to think that<br>
> these for-profit companies will long expend shareholder owned assets<br>
> without expectation of some compensating business advantage or revenue<br>
> stream.<br>
> <br>
> The legacy root server system has one characteristic that we too often<br>
> overlook: It is run at an extremely high level of professionalism. It<br>
> is so high that there is usually no incentive to look to any other<br>
> offering.<br>
> <br>
> And that professionalism has little to do with ICANN.<br>
> <br>
> For instance, remember the limitation (caused by the way that names are<br>
> encoded into 512 byte UDP DNS packets) that places a limit of about 13<br>
> root name servers? Remember the contention that that caused in the<br>
> early days of ICANN because those 13 places were not equitably<br>
> distributed around the world? It was not ICANN that came up with the<br>
> notion of anycast groups of name servers, rather it was the external<br>
> community that created the idea and it was the root server operators<br>
> who<br>
> went forth and did the work to make it happen - they did not give ICANN<br>
> notice of this, nor await ICANN permission, nor did they ask for ICANN<br>
> funding - they just did it. And as a result, the net is a better<br>
> place.<br>
> <br>
> DNS technology is not the perfect answer to all questions - I've<br>
> written<br>
> about how DNS is insufficient to support the naming needs of net based<br>
> distributed applications that move, split, and merge like blobs in a<br>
> lava lamp. E.g. My 2010 note "On Entity Associations In A Cloud<br>
> Network" <a href="https://www.cavebear.com/archive/public/cloud-entities.pdf" rel="noreferrer" target="_blank">https://www.cavebear.com/archive/public/cloud-entities.pdf</a><br>
> <br>
> And I see some well intentioned efforts that are trying to push DNS for<br>
> uses that it is not necessarily appropriate or in ways that could<br>
> create<br>
> unnecessary risks of code flaws that could lead to attacks or security<br>
> vulnerabilities (this is especially true in the Internet-of-Things<br>
> world<br>
> where code is often weak and relies on use in a confined, non-stressful<br>
> network environment. For example, should the coming generation of<br>
> TCP/IP based Engine Control Units [ECU] in a vehicle have to implement<br>
> Punycode and UTF-8 or ought they take the safer path of simply<br>
> rejecting<br>
> any non-ASCII names?)<br>
> <br>
> --karl--<br>
> <br>
> On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:<br>
> <br>
> I suspect it may well be too late (20 years too late!) to use the<br>
> "reserve for posterity" approach for namespaces. A call to do this<br>
> would<br>
> no doubt be taken up at WIPO not ICANN anyway given the long<br>
> standing<br>
> issue with ICANN surrendering names as solely for business and<br>
> governmental utility over its designed use for edge to edge<br>
> resolution<br>
> services. That would further push DNS away from the Internet edge<br>
> and so<br>
> itself be destabilising.<br>
> <br>
> There's also a question whether the single root argument made by<br>
> IAB<br>
> in 2000 is still gospel in a world where e2e offers secure<br>
> frameworks for attestations of an infinite variety of namespaces<br>
> and<br>
> identifiers than is even conceivable for the DNS infrastructure.<br>
> <br>
> Particularly as DNS resolution is interpretative (punycode etc)<br>
> today<br>
> and largely anycast with geographical routing depending source and<br>
> destination addressing which in turn depend on unofficial geo IP<br>
> databases which are far from dependable given the growth in over<br>
> and<br>
> under private networks using their own choice of gateways into the<br>
> "Internet". I am almost never in the place "The Internet" tells me<br>
> I am<br>
> in!<br>
> <br>
> But I take your insider political perspective on the ICANN<br>
> firmament. But it rather confirms my concern that ICANN has been<br>
> far to<br>
> comfortable with the DNS industry as a private club believing<br>
> everybody<br>
> has to go through the DNS that it "controls".<br>
> <br>
> The reality is ICANN does not control the DNS just access to the<br>
> root<br>
> server resolution system. That is implemented as a tax and<br>
> unsurprising<br>
> if users think differently<br>
> <br>
> C<br>
> <br>
> <br>
> Alejandro Pisanty via At-Large <<a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a>><br>
> writes:<br>
> <br>
> <br>
> 1. ( ) text/plain (*) text/html<br>
> <br>
> Matthias,<br>
> <br>
> thanks very much for this rich information. The summaries alone<br>
> should be considered as strong alarm signs. The<br>
> foci of attention of ALAC and At-Large seem way out of phase,<br>
> lagging years behind these developments. This is<br>
> not uniform; some RALOs are in even worse shape, considering<br>
> recent publicly available evidence.<br>
> <br>
> Alejandro Pisanty<br>
> <br>
> On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via<br>
> At-Large <<a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a>> wrote:<br>
> <br>
> Hi colleagues, the SSAC has published SAC123 and SAC122.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> ### SSAC Report on the Evolution of Internet Name Resolution<br>
> (SAC123):<br>
> <br>
> · Internet name resolution is evolving beyond just the global<br>
> DNS to include alternative naming systems<br>
> that are experimenting with different approaches for reasons<br>
> like speed, privacy, censorship resistance, and<br>
> governance.<br>
> <br>
> · Many alternative systems adopt DNS name syntax to leverage<br>
> existing software.<br>
> <br>
> · Two concerning trends are increased ambiguity where the same<br>
> name can resolve differently in<br>
> different systems, and less visibility of names to end users<br>
> even as names remain vital for security and trust.<br>
> <br>
> · Maintaining integrity and coordination in the shared domain<br>
> namespace is important.<br>
> <br>
> · The report explores different perspectives on these trends<br>
> from end users and developers.<br>
> <br>
> · It identifies proposals to facilitate namespace coordination<br>
> and recommends ICANN continue tracking<br>
> these issues and provide regular updates to the community.<br>
> <br>
> I highly recommend having a look at chapter: 7.1 End Users<br>
> (some key aspects as follows):<br>
> <br>
> · Domain names used to play an important role for end users in<br>
> discovering web resources, but search<br>
> engines have now replaced them as the primary method of<br>
> discovery.<br>
> <br>
> · End users today rarely directly interact with domain names<br>
> due to the dominance of search engines and<br>
> mobile devices. Features like browser "omnibars" also allow<br>
> more free-form input.<br>
> <br>
> · Other identifiers like QR codes and social media handles now<br>
> also compete for users' attention rather<br>
> than domain names.<br>
> <br>
> · Domain names are becoming less visible in users'<br>
> environments, yet they still provide an underlying<br>
> ubiquitous resolution context relied upon by other<br>
> technologies.<br>
> <br>
> · Surveys found search engines are by far the predominant<br>
> method for accessing websites, with domain<br>
> name usage declining. QR code usage is increasing but still<br>
> limited except in Asia.<br>
> <br>
> · Decreased domain name visibility makes it easier for<br>
> fraudsters to deceive users with lookalike names.<br>
> Users are also generally unaware that some TLDs signal a<br>
> different resolution context.<br>
> <br>
> In summary, domain names are no longer the primary method end<br>
> users employ to find and access Internet<br>
> resources, decreasing their visibility and understandability<br>
> while introducing security issues.<br>
> <br>
> <br>
> <br>
> Link to the report:<br>
> <a href="https://itp.cdn.icann.org/en/files/" rel="noreferrer" target="_blank">https://itp.cdn.icann.org/en/files/</a><br>
> security-and-stability-advisory-committee-ssac-reports/<br>
> sac-123-15-12-2023-en.pdf<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> ### SSAC Report on Urgent Requests in gTLD Registration Data<br>
> Policy (SAC122)<br>
> <br>
> · Focus is on handling of Urgent Requests in proposed gTLD<br>
> registration data policy<br>
> <br>
> · Urgent Requests refer to imminent threats to life, injury,<br>
> infrastructure or child exploitation<br>
> <br>
> · Proposed policy requires response to Urgent Requests in 24<br>
> hours generally<br>
> <br>
> · SSAC contends proposed policy for Urgent Requests is not fit<br>
> for purpose<br>
> <br>
> · Definition and required response times are incompatible<br>
> <br>
> · Questions if need and rationale for separate Urgent Request<br>
> process is fully justified<br>
> <br>
> · Existing ICANN policy and industry practices offer useful<br>
> precedents<br>
> <br>
> · Proposed extensions allow responses up to 7 days, not<br>
> reflecting urgency<br>
> <br>
> · Lack of concrete data on frequency and handling of such<br>
> requests currently<br>
> <br>
> · Risks reputation of ICANN multistakeholder model<br>
> effectiveness<br>
> <br>
> - Provides 3 recommendations<br>
> <br>
> § Add structure to ensure Urgent Requests handled expediently<br>
> <br>
> § Tighten response time requirements to be fit for purpose<br>
> <br>
> § Gather data on Urgent Requests for future policy making<br>
> <br>
> Link to the report:<br>
> <a href="https://itp.cdn.icann.org/en/files/" rel="noreferrer" target="_blank">https://itp.cdn.icann.org/en/files/</a><br>
> security-and-stability-advisory-committee-ssac-reports/<br>
> sac-122-12-12-2023-en.pdf<br>
> <br>
> <br>
> <br>
> <br>
> Have a nice evening!<br>
> <br>
> Best,<br>
> <br>
> M.<br>
> <br>
> <br>
> <br>
> ______________________________<br>
> <br>
> Ing. Mag. Matthias M. Hudobnik<br>
> <br>
> FIP • CIPP/E • CIPT • DPO • CIS LA<br>
> <br>
> <a href="mailto:matthias@hudobnik.at" target="_blank">matthias@hudobnik.at</a><br>
> <br>
> <a href="http://www.hudobnik.at" rel="noreferrer" target="_blank">http://www.hudobnik.at</a><br>
> <br>
> @mhudobnik<br>
> <br>
> _______________________________________________<br>
> At-Large mailing list<br>
> <a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
> <a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
> <br>
> At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><br>
> _______________________________________________<br>
> By submitting your personal data, you consent to the processing<br>
> of your personal data for purposes of<br>
> subscribing to this mailing list accordance with the ICANN<br>
> Privacy Policy<br>
> (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of<br>
> Service<br>
> (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman<br>
> link above to change your membership status<br>
> or configuration, including unsubscribing, setting digest-style<br>
> delivery or disabling delivery altogether (e.g.,<br>
> for a vacation), and so on.<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> At-Large mailing list<br>
> <a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
> <a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
> <br>
> At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><br>
> _______________________________________________<br>
> By submitting your personal data, you consent to the processing of your<br>
> personal data for purposes of subscribing to this mailing list<br>
> accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy" rel="noreferrer" target="_blank">https://www.icann.org/privacy</a><br>
> /policy) and the website Terms of Service (<a href="https://www.icann.org/" rel="noreferrer" target="_blank">https://www.icann.org/</a><br>
> privacy/tos). You can visit the Mailman link above to change your<br>
> membership status or configuration, including unsubscribing, setting<br>
> digest-style delivery or disabling delivery altogether (e.g., for a<br>
> vacation), and so on.<br>
> <br>
> _______________________________________________<br>
> At-Large mailing list<br>
> <a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
> <a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
> <br>
> At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><br>
> _______________________________________________<br>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<br>
<br>
-- <br>
-Barry Shein<br>
<br>
Software Tool & Die | bzs@TheWorld.com | <a href="http://www.TheWorld.com" rel="noreferrer" target="_blank">http://www.TheWorld.com</a><br>
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD<br>
The World: Since 1989 | A Public Information Utility | *oo*<br>
_______________________________________________<br>
At-Large mailing list<br>
<a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
<br>
At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div></div>