RSSAC002v5: New title for section 3.1
Dear RSSAC Caucus Members, I had an action item to propose a new title for §3.1 in RSSAC002v5. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...> Once the new title is determined I will then affect the language throughout the section in accordance with its new title. First I thought about some terms for time durations in networking. time, latency, lag, delay ‘latency’ would seem the obvious choice, but my problem with ‘latency’ is that it often refers to a mean over many trips. When we talk about ‘high latency’ in networking we’re usually referring to many trips, or a state of the network, whereas here we’re talking about a single transfer of data. ‘latency’ like ‘delay’ and ‘lag’ are also negative. We can add qualifiers to both like ‘low-‘, but without that qualifier it has negative connotations. This leaves me with ’time’, because it does not evoke a mean or negativity. And then I considered the definitions of publish and serve from RSSAC026v2. <https://www.icann.org/en/system/files/files/rssac-026-lexicon-12mar20-en.pdf> The period we’re titling here is between publishing and serving root zone data. More specifically it is between receipt of a NOTIFY message from the Root Zone Maintainer until 95% of the RSI’s instances are serving the new data. All the other titles in §3 start with ‘The’, and §3.1 needs to blend in. 3.2 The volume of traffic 3.3 The query and response size distribution 3.4 The RCODE distribution 3.5 The number of sources seen So how about this: 3.1 The time elapsed between publishing and serving Thanks, Andrew
Hello Andrew, After checking to document and reading your email I think you are right, it looks the word "time" is much more appropriate. Thanks, On 1/3/23 10:34 AM, Andrew McConachie wrote:
Dear RSSAC Caucus Members,
I had an action item to propose a new title for §3.1 in RSSAC002v5. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...>
Once the new title is determined I will then affect the language throughout the section in accordance with its new title.
First I thought about some terms for time durations in networking. time, latency, lag, delay
‘latency’ would seem the obvious choice, but my problem with ‘latency’ is that it often refers to a mean over many trips. When we talk about ‘high latency’ in networking we’re usually referring to many trips, or a state of the network, whereas here we’re talking about a single transfer of data.
‘latency’ like ‘delay’ and ‘lag’ are also negative. We can add qualifiers to both like ‘low-‘, but without that qualifier it has negative connotations.
This leaves me with ’time’, because it does not evoke a mean or negativity.
And then I considered the definitions of publish and serve from RSSAC026v2. <https://www.icann.org/en/system/files/files/rssac-026-lexicon-12mar20-en.pdf>
The period we’re titling here is between publishing and serving root zone data. More specifically it is between receipt of a NOTIFY message from the Root Zone Maintainer until 95% of the RSI’s instances are serving the new data.
All the other titles in §3 start with ‘The’, and §3.1 needs to blend in. 3.2 The volume of traffic 3.3 The query and response size distribution 3.4 The RCODE distribution 3.5 The number of sources seen
So how about this: 3.1 The time elapsed between publishing and serving
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
On 2 Mar 2023, at 10:53, Ray Bellis <ray@isc.org> wrote:
On 01/03/2023 14:34, Andrew McConachie wrote:
So how about this: 3.1 The time elapsed between publishing and serving
This works for me.
If there isn’t any strong objection on the list by Sunday March 5, I will edit the text of §3.1 to reflect this new title. Then we can discuss the new text on the list. I’m hoping we can cancel the call next week on March 9 because many of us will be travelling and will miss that call. For now the March 9 call is still on, but let’s check back in after I’ve rewritten §3.1. Thanks, Andrew
Hi, I agree with Andrew, "time" is more suitable here. We can even title it as "publishing time" or "convergence time" (similar to OSPF). Regards Hafiz Farooq --- This message has been scanned via Symantec MessageLabs & SpamDefense Engine On Thu, Mar 2, 2023 at 1:25 PM Andrew McConachie < andrew.mcconachie@icann.org> wrote:
On 2 Mar 2023, at 10:53, Ray Bellis <ray@isc.org> wrote:
On 01/03/2023 14:34, Andrew McConachie wrote:
So how about this: 3.1 The time elapsed between publishing and serving
This works for me.
If there isn’t any strong objection on the list by Sunday March 5, I will edit the text of §3.1 to reflect this new title. Then we can discuss the new text on the list.
I’m hoping we can cancel the call next week on March 9 because many of us will be travelling and will miss that call. For now the March 9 call is still on, but let’s check back in after I’ve rewritten §3.1.
Thanks, Andrew_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
So how about this: 3.1 The time elapsed between publishing and serving
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long. --Paul Hoffman
I hate to highjack this email string, but I have a pressing question. E-Root experienced an Exact prefix hijack of prefix 2001:500:a8::/48 and was notified of this by CodeBGP. My SOC/NOC are interested in finding out how ICANN ( or other agency) responds to these types of incidents. Since this was not an issue with out server we need to have someone who can reach out to the offending party to correct. Who can a talk to regarding this event? Barbara Schleckser DNS, DHCP, and IP Address Management (DDI) Service Element Manager Enterpise Software Services Service Element Manager E-Root Service Manager Network and Telecommunications Services (NaTS) NASA 256-624-0178 (Cell) Barbara.g.schleckser@nasa.gov -----Original Message----- From: rssac-caucus <rssac-caucus-bounces@icann.org> On Behalf Of Paul Hoffman Sent: Thursday, March 2, 2023 11:46 AM To: Andrew McConachie <andrew.mcconachie@icann.org> Cc: RSSAC Caucus <rssac-caucus@icann.org> Subject: [EXTERNAL] Re: [RSSAC Caucus] RSSAC002v5: New title for section 3.1 On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
So how about this: 3.1 The time elapsed between publishing and serving
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long. --Paul Hoffman _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o... _______________________________________________ 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 (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....) and the website Terms of Service (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....). 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.
Barbara, I will contact you off thread John Crain ICANN Sent from my iPhone
On Mar 2, 2023, at 11:43 AM, Schleckser, Barbara G. (MSFC-IS64) via rssac-caucus <rssac-caucus@icann.org> wrote:
I hate to highjack this email string, but I have a pressing question. E-Root experienced an Exact prefix hijack of prefix 2001:500:a8::/48 and was notified of this by CodeBGP. My SOC/NOC are interested in finding out how ICANN ( or other agency) responds to these types of incidents. Since this was not an issue with out server we need to have someone who can reach out to the offending party to correct. Who can a talk to regarding this event?
Barbara Schleckser DNS, DHCP, and IP Address Management (DDI) Service Element Manager Enterpise Software Services Service Element Manager E-Root Service Manager Network and Telecommunications Services (NaTS) NASA 256-624-0178 (Cell) Barbara.g.schleckser@nasa.gov
-----Original Message----- From: rssac-caucus <rssac-caucus-bounces@icann.org> On Behalf Of Paul Hoffman Sent: Thursday, March 2, 2023 11:46 AM To: Andrew McConachie <andrew.mcconachie@icann.org> Cc: RSSAC Caucus <rssac-caucus@icann.org> Subject: [EXTERNAL] Re: [RSSAC Caucus] RSSAC002v5: New title for section 3.1
On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote: So how about this: 3.1 The time elapsed between publishing and serving
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?... [gcc02[.]safelinks[.]protection[.]outlook[.]com]
_______________________________________________ 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 (https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?... [gcc02[.]safelinks[.]protection[.]outlook[.]com]) and the website Terms of Service (https://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.com/?... [gcc02[.]safelinks[.]protection[.]outlook[.]com] U5cDE1GNeCRAJvwKs4rP0btjsbD8FBMDhs%3D&reserved=0). 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. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
I would appreciate something like an IEPG presentation on this one, from anyone involved in the incident detection, remediation and analysis. It might also be a SIDROPS thing, but IEPG feels like a good fit, or DNS-OARC. Realising some aspects of the security posture can't be talked about, this is fundamentally a problem in public utility services, and against the public utility routing model (BGP) so the role of a ROA, or other mechanistic defences stands as something I think we (the community at large) would want a chance to talk about. I'd be fascinated (for instance) how widely this was "seen" given the anycast nature of service delivery. cheers, and commiserations to anyone involved in the problem. -George On Fri, Mar 3, 2023 at 5:43 AM Schleckser, Barbara G. (MSFC-IS64) via rssac-caucus <rssac-caucus@icann.org> wrote:
I hate to highjack this email string, but I have a pressing question. E-Root experienced an Exact prefix hijack of prefix 2001:500:a8::/48 and was notified of this by CodeBGP. My SOC/NOC are interested in finding out how ICANN ( or other agency) responds to these types of incidents. Since this was not an issue with out server we need to have someone who can reach out to the offending party to correct. Who can a talk to regarding this event?
Barbara Schleckser DNS, DHCP, and IP Address Management (DDI) Service Element Manager Enterpise Software Services Service Element Manager E-Root Service Manager Network and Telecommunications Services (NaTS) NASA 256-624-0178 (Cell) Barbara.g.schleckser@nasa.gov
-----Original Message----- From: rssac-caucus <rssac-caucus-bounces@icann.org> On Behalf Of Paul Hoffman Sent: Thursday, March 2, 2023 11:46 AM To: Andrew McConachie <andrew.mcconachie@icann.org> Cc: RSSAC Caucus <rssac-caucus@icann.org> Subject: [EXTERNAL] Re: [RSSAC Caucus] RSSAC002v5: New title for section 3.1
On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
So how about this: 3.1 The time elapsed between publishing and serving
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o...
_______________________________________________ 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 (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....) and the website Terms of Service (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.... U5cDE1GNeCRAJvwKs4rP0btjsbD8FBMDhs%3D&reserved=0). 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. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
On 02/03/2023 22:11, George Michaelson wrote:
I would appreciate something like an IEPG presentation on this one, from anyone involved in the incident detection, remediation and analysis. It might also be a SIDROPS thing, but IEPG feels like a good fit, or DNS-OARC.
IEPG clashes with the regular meeting of the Root Operators.
Realising some aspects of the security posture can't be talked about, this is fundamentally a problem in public utility services, and against the public utility routing model (BGP) so the role of a ROA, or other mechanistic defences stands as something I think we (the community at large) would want a chance to talk about.
I'd be fascinated (for instance) how widely this was "seen" given the anycast nature of service delivery.
cheers, and commiserations to anyone involved in the problem.
We've also had a couple of recent incidents (one was the same as the reported E-root incident) but we've as yet not managed to get any useful response from the (APNIC region) sources. We still believe it's likely that this was incompetence rather than malice, though. There feels like little else we can do, since F-root's prefixes are RPKI signed. Ray
Hello, I do agree with presenting this during an IEPG meeting, sounds interesting, however, maybe at the end is not different from other prefix hijacks all of us have seem before. Regards, Alejandro, P.S. The prefix 2001:500:a8::/48 does not appear to have a RPKI ROA but has IRR P.S2. I don't think it's possible, but it would be nice if there is a way to "simulate" what could have happen (scope) if the prefix would have had a ROA. On 2/3/23 6:11 PM, George Michaelson wrote:
I would appreciate something like an IEPG presentation on this one, from anyone involved in the incident detection, remediation and analysis. It might also be a SIDROPS thing, but IEPG feels like a good fit, or DNS-OARC.
Realising some aspects of the security posture can't be talked about, this is fundamentally a problem in public utility services, and against the public utility routing model (BGP) so the role of a ROA, or other mechanistic defences stands as something I think we (the community at large) would want a chance to talk about.
I'd be fascinated (for instance) how widely this was "seen" given the anycast nature of service delivery.
cheers, and commiserations to anyone involved in the problem.
-George
On Fri, Mar 3, 2023 at 5:43 AM Schleckser, Barbara G. (MSFC-IS64) via rssac-caucus <rssac-caucus@icann.org> wrote:
I hate to highjack this email string, but I have a pressing question. E-Root experienced an Exact prefix hijack of prefix 2001:500:a8::/48 and was notified of this by CodeBGP. My SOC/NOC are interested in finding out how ICANN ( or other agency) responds to these types of incidents. Since this was not an issue with out server we need to have someone who can reach out to the offending party to correct. Who can a talk to regarding this event?
Barbara Schleckser DNS, DHCP, and IP Address Management (DDI) Service Element Manager Enterpise Software Services Service Element Manager E-Root Service Manager Network and Telecommunications Services (NaTS) NASA 256-624-0178 (Cell) Barbara.g.schleckser@nasa.gov
-----Original Message----- From: rssac-caucus <rssac-caucus-bounces@icann.org> On Behalf Of Paul Hoffman Sent: Thursday, March 2, 2023 11:46 AM To: Andrew McConachie <andrew.mcconachie@icann.org> Cc: RSSAC Caucus <rssac-caucus@icann.org> Subject: [EXTERNAL] Re: [RSSAC Caucus] RSSAC002v5: New title for section 3.1
On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
So how about this: 3.1 The time elapsed between publishing and serving That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o...
_______________________________________________ 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 (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann....) and the website Terms of Service (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.... U5cDE1GNeCRAJvwKs4rP0btjsbD8FBMDhs%3D&reserved=0). 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. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
On Mar 2, 2023, at 7:00 PM, Alejandro Acosta <alejandro@lacnic.net> wrote:
P.S2. I don't think it's possible, but it would be nice if there is a way to "simulate" what could have happen (scope) if the prefix would have had a ROA.
This essentially did happen because two prefix hijacks happened at the same time: 2001:500:a8::/48 (NASA) and 2001:500:2f::/48 (ISC). The first does not have a ROA but the second does. According to our preliminary investigation, the hijacked prefix without ROA was seen at 5 of 520 vantage points, while the prefix with ROA was seen at 2 of 520. DW
On 3/3/23 11:28 AM, Wessels, Duane wrote:
On Mar 2, 2023, at 7:00 PM, Alejandro Acosta <alejandro@lacnic.net> wrote:
P.S2. I don't think it's possible, but it would be nice if there is a way to "simulate" what could have happen (scope) if the prefix would have had a ROA. This essentially did happen because two prefix hijacks happened at the same time: 2001:500:a8::/48 (NASA) and 2001:500:2f::/48 (ISC). The first does not have a ROA but the second does. According to our preliminary investigation, the hijacked prefix without ROA was seen at 5 of 520 vantage points, while the prefix with ROA was seen at 2 of 520.
This is quite interesting, thanks for sharing, nice catch, RPKI did his job :-) I was not aware of the F root, I will take a look. Thanks,
DW
On 2 Mar 2023, at 18:46, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Mar 1, 2023, at 6:34 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
So how about this: 3.1 The time elapsed between publishing and serving
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long.
My title leans heavily into the definitions of publish and serve from RSSAC026v2. "Publishing the root zone is the activity performed by the root zone maintainer when preparing a new version of the root zone and entering it into the root zone distribution system. Serving the root zone is the activity performed by the root server system using the acquired information.” Is your “receipt of a new zone” synonomous with RSSAC026v2’s definition of publish? —Andrew
On 02/03/2023 17:46, Paul Hoffman wrote:
That seems too abbreviated, but might be OK. The best I could come up with is "The time elapsed between receipt of a new zone and serving", which may be too long.
I don't think that's a useful title. We're not trying to measure how long a name server takes to start using the zone data once it has received it. We're trying to measure how long it takes the data to propagate from the RZM to the name server instances. We did discuss that there might be a short delay between zone "receipt" and serving, but that's of the order of a second or so, and lost in the noise. Ray
I think that Andrew’s suggested title is good and the logic seems sound. I also think that using ‘time’ in the section title is very sensible since we agree (I think) that the value of the metric should be expressed in seconds. Russ
On Mar 1, 2023, at 9:34 AM, Andrew McConachie <andrew.mcconachie@icann.org <mailto:andrew.mcconachie@icann.org>> wrote:
Dear RSSAC Caucus Members,
I had an action item to propose a new title for §3.1 in RSSAC002v5. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h... <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0hdZ0/>>
———————————————> snip <—————————
So how about this: 3.1 The time elapsed between publishing and serving
Thanks, Andrew _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
Dear RSSAC Caucus Members, I’ve made edits to Section 3.1 in alignment with the new title. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...> I also corrected the reference in Section 5. Please review the new language in Section 3.1. Thanks, Andrew
On 3 Mar 2023, at 23:15, Russ Mundy <mundy@tislabs.com> wrote:
I think that Andrew’s suggested title is good and the logic seems sound.
I also think that using ‘time’ in the section title is very sensible since we agree (I think) that the value of the metric should be expressed in seconds.
Russ
On Mar 1, 2023, at 9:34 AM, Andrew McConachie <andrew.mcconachie@icann.org <mailto:andrew.mcconachie@icann.org>> wrote:
Dear RSSAC Caucus Members,
I had an action item to propose a new title for §3.1 in RSSAC002v5. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...>
———————————————> snip <—————————
So how about this: 3.1 The time elapsed between publishing and serving
Thanks, Andrew _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
On Mar 7, 2023, at 1:57 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
I’ve made edits to Section 3.1 in alignment with the new title. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...>
I also corrected the reference in Section 5.
Please review the new language in Section 3.1.
The new language looks good, and I like Dessalegn's change as well. --Paul Hoffman
+1 to Paul - I think these changes take care of the problem we discussed in our last meeting. Russ
On Mar 7, 2023, at 1:19 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Mar 7, 2023, at 1:57 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
I’ve made edits to Section 3.1 in alignment with the new title. <https://docs.google.com/document/d/187k3b64DgkeCM6ib6ny6Ok7LzNxdT_v5X6FE0l0h...>
I also corrected the reference in Section 5.
Please review the new language in Section 3.1.
The new language looks good, and I like Dessalegn's change as well.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
participants (10)
-
Alejandro Acosta -
Andrew McConachie -
George Michaelson -
Hafiz Farooq -
John Crain -
Paul Hoffman -
Ray Bellis -
Russ Mundy -
Schleckser, Barbara G. (MSFC-IS64) -
Wessels, Duane