Eliot: Please see my responses to each comment below. In addition, the authors have produced a PR to implement the changes:
https://github.com/paulehoffman/9280-updates/pull/2 Russ > From Eliot Lear[1]: > Section 6.1: > >> To be absolutely clear, the Trust retains rights to manage IPR, so I suggest >> the following changes: >> >> OLD: >> >> It was left to the >> Trust to specify exactly how this shall be clearly indicated in each >> document. >> >> NEW: >> >> It is left to the >> Trust to specify exactly how this shall be clearly indicated in each >> document. > > > This is substantial, but hopefully not controversial. I think we just make this change. The timing may be that we want to use "IETF IPMC" instead of "Trust". The IETF Trust will clearly not exist by the end of the year, and the IETF IPMC has already come into existence. > He continues: > >> The Chapeau in Section 7 now looks a little funny, and historically wrong, >> given that we appear to be changing history. To this end, I suggest the >> following changes: >> >> OLD: >> >> 7. Historical Properties of the RFC Series >> >> NEW: >> >> 7. Properties of the RFC Series >> >> OLD: >> >> This section lists some of the properties that have been historically >> >> regarded as important to the RFC Series. >> >> NEW: >> >> This section lists some of the properties that are >> >> regarded as important to the RFC Series. > > We don't think these are substantial based on the definitions above. > However, a broader conversation relating to Section 7 did ensue in the RSWG. > Therefore, we suggest that the authors address the above points, but the RSWG > chairs address the any changes that should be made based on further RSWG > discussion. > We reject this comment. This revision changes some of these properties. That is the point of the section. > Finally, Eliot concludes: > >> One last nit: >> >> Section 9.5: >> >> OLD: >> >> To overcome some of these issues, [RFC9280] dispenses with the RSOC. >> >> NEW: >> >> To overcome some of these issues, [RFC9280] dispensed with the RSOC. > > This is not substantial. Seems fine. > Next, Mike St. Johns made several comments as follows: > > >> Section 3.1.1.3 - Reads poorly. Instead "The RSWG has two chairs, one >> appointed by the IAB and one by the IESG. Both chairs serve staggered >> 2-year terms, with the IAB-appointed chair's term beginning (and ending) at >> the end of the First IETF meeting in [even|odd] years, and the >> IESG-appointed chair similarly in [even|odd] years. Chairs may be >> reappointed to additional terms at the discretion of the appointing body." > > This is not substantial. Does it need to say anything more than: "The RSWG has two chairs, one appointed by the IAB and one by the IESG." If a chair were to resign before the term ends, the cadence will get messed up. > In that same section: >> >> s/determined/determine/ - they can change at any time rather than implying >> the choice is fixed. > > This is substantial, but hopefully not controversial. Seems fine. > Referring to that same section: >> >> In the line about directing comments - why not actually state the >> current mechanism(s) now that we know it? E.g. send it to which email list >> or drop box or comment page? > > This is substantial. Maybe it would be better to just say comments are sought from the community. It could give an example of asking for comments on appropriation email lists. > And again referring to that same section: > >> s/have the power to remove/may remove/ > > This is not substantial. Seems fine. > Next: > >> Section 3.1.1.4 - 2nd to last para "The IETF LLC, through agreement, >> provides....". Delete the last paragraph. > > Mike is referring to the following text: > > The IAB convened the RSWG in 2022 in order to formalize the IAB's > transfer of authority over the RFC Editor Model. > > This is not substantial. Seems fine. > Next: > >> Section 3.1.2.6 Ditto for the RSAB operation. > > Mike is referring to the following text: > > The IAB convened the RSAB in 2022 in order to formalize the IAB's > transfer of authority over the RFC Editor Model. > > This is not substantial. Seems fine. > Mike's last comment: > >> Section 5.2 - this didn't change, but I think it needs to. This has the >> tail wagging the dog. The RCSE works (is employeed by or contracted) for >> the LLC who has hire/fire authority. The LLC needs input FROM the RSAB (or >> its members individually) and it's unclear that providing an internal LLC >> evaluation to the RSAB is a legitimate approach. That said, the LLC can >> involve the IAB and IESG chairs as an LLC discussion if they think it >> necessary. I don't expect this to fly given that the RSAB is writing the >> document, but it's worth a try. > > This is substantial. We should reject this one. > Finally, during his review, Roman raised a question about > >> Consistent with Step 6 of Section 3.2.2 of RFC9280 which said “Once >> consensus is established in the RSWG, … RSAB itself shall also consider the >> proposal”, my additional feedback is that this text in Section 1.2/Section 8 >> is unclear on the intent. >> >> Updates, amendments, and refinements to this document can be produced >> using the process documented herein but, unless otherwise specified >> in this document, shall be published and operative only after (a) >> obtaining the agreement of the IAB and the IESG and (b) ensuring that >> the IETF LLC has no objections regarding its ability to implement any >> proposed changes. >> >> The newly inserts text of “unless otherwise specified in this document” >> introduces ambiguity: >> >> -- Does the “unless otherwise specified by this document” negate the need to >> conduct consultation (a) and (b)? If something is specified in the >> document, is that removed from the scope of what could be consulted about >> through (a) and (b)? >> >> -- How can a document “specify” something to create a review exclusion >> without being “published”, but the existing text requires consultation >> through (a) and (b) to be published? > > This point should be addressed as substantial. > Revise Section 8, and remove Section 1.2. Russ
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
