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]> 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]> on behalf of " > [email protected]" <[email protected]> > *Date: *Wednesday, November 21, 2018 at 2:35 AM > *To: *SPRING WG List <[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] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
