Hi Ruediger, all My 2c, speaking as an individual contributor,
Thanks for the feedback and arguments. As a network operator, network interoperability is also very important to me. IMHO, interoperability issues may be detected at different stages: specification, vendors tests in lab, operators tests in lab, early deployments, years after deployment for specific conditions. Obviously, the sooner the better so as to improve feature velocity, reduce cost and customers impact, for the (high level) benefit of everyone. I see the IETF mainly involved in the specification part, which is an important part to me as ideally all/most interop issues would be identified at this stage (1)... assuming large efforts from authors and from the WG to reviews the documents. I can see that implementation experience(s) helps in detecting specification issues, and that multiple implementations experience helps in pinpointing underspecified parts. On the other hand, requiring N implementations before progressing a document is likely to delay reviews of specifications from the WG and IESG, possibly delay deployments for some network operators (waiting for mature specification), and can possibly delay sourcing/multiple implementations. All of these being counter-productive for early identification of interop issues. > As that requires effort for finished work This may indeed be the main point. And it's a bit up to all of us. In addition to implementation policy, we could also debate "Review Requirement Policy" for WG documents. e.g. "requires N technical reviews". Regards, --Bruno (1) May be debatable, but some dreaming is allowed and may help raising the bar. From: [email protected] [mailto:[email protected]] Sent: Wednesday, November 21, 2018 12:15 PM To: DECRAENE Bruno TGI/OLN Cc: [email protected] Subject: AW: Implementation Requirement Policy Hi Bruno, my preference is for a). Interoperability is a requirement discussed with vendors ahead of implementation. The sooner issues are discovered and removed, the better. The interoperable implementations should be from completely independent implementors. The detailed implementation report helps too, in case there are debates on what "interoperability" means later on. To make such a report more useful, a review on commodity features should follow a while after a draft standard saw implementation. That would help to remove or at least indicate features which didn't see deployment. As that requires effort for finished work, it will stay a wish, I guess. Regards, Ruediger Von: spring <[email protected]> Im Auftrag von [email protected] Gesendet: Mittwoch, 21. November 2018 08:35 An: SPRING WG List <[email protected]> Betreff: [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. _________________________________________________________________________________________________________________________ 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
