Andy, Zafar and Ruediger thanks for the feedback. Another difference between (e) and (f) may be the timing of the disclosure: - (f) is typically performed after Working Group last call, hence after the work in the WG - (e) gives a chance to the WG and more generally the networking community to get this knowledge during the lifetime of the draft / WG work. (1)
Cheers, Bruno (1) Assuming this work is indeed done by the authors/WG and updated somewhat regularly. From: Andrew G. Malis [mailto:[email protected]] Sent: Tuesday, December 04, 2018 3:10 PM To: Zafar Ali (zali) Cc: DECRAENE Bruno TGI/OLN; SPRING WG List Subject: Re: [spring] Implementation Requirement Policy Zafar, Actually, most WGs (to my knowledge as a WG chair) follow (f) rather than (e), and the implementation information is included in the writeup from the document shepherd to the IESG rather than in the draft itself. Note that the writeup is a public document and is, and to my knowledge, permanently retained in the datatracker. I'm personally happy with either (e) or (f). Note that (e) rather than (f) shifts the work of gathering and documenting the implementation info from the WG chairs and/or document shepherd to the draft authors and editors. Cheers, Andy On Tue, Dec 4, 2018 at 7:53 AM Zafar Ali (zali) <[email protected]<mailto:[email protected]>> wrote: Hi Bruno and the WG, I think option (e) is most reasonable and is something most documents already follow as part of the IETF publication process. Thanks Regards … Zafar From: spring <[email protected]<mailto:[email protected]>> on behalf of "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, November 21, 2018 at 2:35 AM To: SPRING WG List <[email protected]<mailto:[email protected]>> Subject: [spring] Implementation Requirement Policy Hi SPRING, As introduced during IETF 103, the IESG asked for each WG to discuss the Implementation Requirement Policy that they would like to use. Below are typical examples of implementation requirement policy, but we are free to define our own: 1. require at least 2 interoperable implementations and detailed implementation reports 2. require x implementations documented in an Implementation Status Section (rfc7942) 3. require x implementations — no specific documentation needed 4. require x implementations, but the Chairs can make exceptions per-document 5. document known implementations in the Implementation Status Section (rfc7942) 6. the Chairs will ask about implementations 7. no requirement Note that we are free to use any text, and in particular allow for exceptions in addition to a general rule. Such policy would apply to documents in the SPRING WG. A protocol extension required for SPRING but adopted in another WG (e.g. LSR) would be subject to the policy of its WG (LSR). This email starts a 4-weeks discussion on this. Please voice your preference, and your reasoning. Thanks, --Bruno, Rob _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
