RSSAC001v2 WP Meeting#2 Notes
Dear RSSAC Caucus Members, Here are the recordings from today’s RSSAC001v2 Work Party meeting. August 29, 2022. < https://icann.zoom.us/rec/share/pdYwZSz-b03hiXBkHVLbG3L6d3Y5JWnNiCTzfFExtblf...> _Decisions_ The WP selected Duane Wessels to lead the WP. The WP will meet at ICANN75 (with remote participation) on Tuesday, 20 September 2022 at 02:30 UTC (10:30 MYT) _Actions_ Staff to compile RSO responses to RSSAC001. WP members to study RSSAC001 in detail and propose suggestions to the working document. WP members to study RSSAC001 section 3 in detail and decide whether the expectations are in the right section. _Topics for further discussion_ How to phrase the requirements in RSSAC001v2? What’s RSSAC001v2’s relationship with RFC7720: (1) fold RFC7720 into RSSAC001v2, (2) update RFC7720 in tandem with RSSAC001v2? (3) ??? Adding a terminology section? Adding a motivation paragraph in each of the sections in 3.1, and possibly link to RSSAC055? Working Document <https://docs.google.com/document/d/1fTRTplssJUayL6XD-qAmkGltXOxmeuPe/edit?us...> Thanks, Steve Sheng
Le 29 août 2022 à 12:23, Steve Sheng <steve.sheng@icann.org> a écrit :
...
_Topics for further discussion_ How to phrase the requirements in RSSAC001v2? What’s RSSAC001v2’s relationship with RFC7720: (1) fold RFC7720 into RSSAC001v2, (2) update RFC7720 in tandem with RSSAC001v2? (3) ???
Humm. I think we have discussed that in length, especially when Lars and I were editing RFC7720. IETF specifies the high-level requirements from its point of view. ICANN/RSO may go further with their own service requirements. The predecessor of RFC7720 (RFC2870) had exactly the issue of going way too far into service requirements and we move out these in its update which became RFC7720. I think RFC7720 and RSSAC001 should remain (structurally) as they are: RFC7720 is referenced in RSSAC001. When needed, IETF may update its own RFC7720 on his own pace based on its view, and RSSAC001 can be updated at its own pace too. I don’t think it is a good idea to fold/copy RFC7720 into RSSAC001. Sorry if I’m off since I was not on the call today. Regards, Marc.
Adding a terminology section? Adding a motivation paragraph in each of the sections in 3.1, and possibly link to RSSAC055?
Working Document <https://docs.google.com/document/d/1fTRTplssJUayL6XD-qAmkGltXOxmeuPe/edit?us...>
Thanks, Steve Sheng
_______________________________________________ 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 Aug 29, 2022, at 9:33 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
I think RFC7720 and RSSAC001 should remain (structurally) as they are: RFC7720 is referenced in RSSAC001. When needed, IETF may update its own RFC7720 on his own pace based on its view, and RSSAC001 can be updated at its own pace too.
Those seem fine to me. However:
I don’t think it is a good idea to fold/copy RFC7720 into RSSAC001.
Can you say more about this? To me, the eight simple requirements in RFC 7720 could *also* fit into 001v2 as RSSAC expectations on root server operators. Some of them are already enumerated in the RSSAC055 principles. Why not put them in a document of expectations? --Paul Hoffman
Le 29 août 2022 à 13:16, Paul Hoffman <paul.hoffman@icann.org> a écrit :
On Aug 29, 2022, at 9:33 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
I think RFC7720 and RSSAC001 should remain (structurally) as they are: RFC7720 is referenced in RSSAC001. When needed, IETF may update its own RFC7720 on his own pace based on its view, and RSSAC001 can be updated at its own pace too.
Those seem fine to me. However:
I don’t think it is a good idea to fold/copy RFC7720 into RSSAC001.
Can you say more about this?
To me, the eight simple requirements in RFC 7720 could *also* fit into 001v2 as RSSAC expectations on root server operators. Some of them are already enumerated in the RSSAC055 principles. Why not put them in a document of expectations?
Maybe it is my misunderstanding of the « fold » word. (Again I was not part of the call, sorry). I’ve seen other SDOs literally copy a whole RFC and inevitably start modifying it in their own local copy. If the intent is to make citations/extracts with proper reference, then I’m fine. I just want to avoid the above case. Marc.
--Paul Hoffman
participants (3)
-
Marc Blanchet -
Paul Hoffman -
Steve Sheng