Folks, Have we look at our ³forum² such as OpenStack? Do they have something in place there?
Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING [email protected] Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com <http://www.cisco.com/global/CA/> Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information. On 2015-11-26, 9:01 AM, "BESS on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote: >Hi Loa, > >Loa Andersson : >> One can speculate about the reasons for this, but it seems that often >> the decision whether or not to disclose an implementation is outside >> the mandate for people participating in immediate IETF process. > >I would find it quite unlikely to be in a situation where none of the >vendors implementing a stable spec would have the ability of disclosing >it. I would expect the people who are close to the IETF, if they have >an interest in seeing the spec progress, to be able to spend the time so >that someone else sends an appropriate email to [email protected]. > >-Thomas > > > > >> >> On 2015-11-26 06:57, Andrew G. Malis wrote: >>> Based on my experience on both the vendor and operator side, I see some >>> practical problems with this approach: >>> >>> - There are some (many?) operators that won¹t put drafts into an RFP, >>> only RFCs. >>> >>> - There are some (many?) vendors that won¹t implement a draft or RFC, >>>no >>> matter how good the quality, unless they have a customer that wants the >>> feature. That could be an existing customer that needs the feature >>> operationally (which could lead to early implementation), or it could >>>be >>> a prospective customer with an RFP. >>> >>> - Vendors, of course, prioritize their implementation plans, and they >>> usually put RFCs ahead of drafts, since drafts could change before >>> publication, requiring a change in the implementation. >>> >>> For all these reasons, unless there¹s an existing customer that needs a >>> draft¹s features to fix an operational problem, it¹s less common for >>> vendors to implement drafts than RFCs. >>> >>> A better approach might be to do an implementation poll just prior to >>>WG >>> LC (including implementation plans). The WG can then take the results >>>of >>> the poll into consideration during WG LC to see if there¹s a consensus >>> to send it to the IESG. There could be a draft that everyone agrees is >>> really important to get published, but for whatever reason hasn¹t yet >>> been implemented. >>> >>> Cheers, >>> Andy >>> >>> >>> On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Adrian, >>> >>> Thanks. >>> Please see my reactions in-line. >>> >>> -m >>> >>> Le 25/11/2015 01:13, Adrian Farrel a écrit : >>> >>> Yeah, thanks Martin. >>> >>> The slide has... >>> >>> ==Raising the bar?== >>> . Some documents are being pushed to IESG but >>> without any implementation (plan) to support >>> them >>> . We are thinking of "requiring" that at least one >>> implementation exists before handing the >>> document to IESG >>> . Thoughts? >>> >>> The first bullet allows for a plan to implement, the second >>> requires >>> implementation. The use of quotes in the second bullet suggests >>> that you may be >>> considering that the requirement may be flexible. Obviously we >>> have an opening >>> for discussion, but I wonder how you would decide when to be >>> flexible. >>> >>> >>> Good question :-) Indeed, the intent is to not be blindly strict. >>> But defining the margins of flexibility is the tricky part then. >>> I am pretty sure that this will be on a case by case with the >>> default being the 1 implem requirement. >>> I'll take an example: draft-ietf-bess-pta-flags >>> It defines 2 registries as well as a new BGP Extended Community >>> together with the associated processing procedures. The latter is >>> definitely subject to being implemented and as such subject to the >>> requirement we are discussing. >>> However, what this document really does is to define a mechanism in >>> support of specific needs. >>> So I think that this could be a case where we could skip the 1 >>> implem requirement (but apply it to the specs that use pta-flags). >>> >>> The minutes are a good indication of the level of support you >>> received in the >>> room, but not a deep discussion :-) There seems to be some >>> confusion in the >>> discussion between expediting (or unblocking) I-Ds that have an >>> implementation, >>> and delaying (or blocking) I-Ds that don't have >>>implementations. >>> While, in a >>> world of limited resources, the two things are related, ideally >>> we are not >>> significantly gating the progress of one I-D because we are >>>busy >>> processing >>> another. >>> >>> I'd say there are different points of view rather than confusion. >>>In >>> a situation where implementations are not considered mandatory, >>> having one might indeed be a criteria for moving faster through the >>> process but I think this is one amongst several possible other >>> criterion. >>> >>> Now, I really, really support your motivation, viz. to reduce >>> the pointless, >>> unreviewed, unnecessary, or substandard drafts being sent for >>> publication. The >>> question is how to achieve that. >>> >>> The primary intent here is to send to IESG only documents that have >>> an implementation. It makes their case stronger, is a contribution >>> to reducing the load on IESG's shoulders, and also it anyway makes >>> little sense to push through the standardization process an >>> implementable specification but for which no implementation exists. >>> The moment to submit to iesg is definitely a good time (and the >>>last >>> possible from a chair's perspective) to think about that. >>> >>> Now, your two sentences above open the door to a broader set of >>> potential actions that could be taken to reach the objective, >>> actions which are relevant during the I-D life cycle within the WG. >>> But I guess this is a broader discussion. >>> >>> >>> >>> Adrian (still thinking about this) >>> >>> -----Original Message----- >>> From: BESS [mailto:[email protected] >>> <mailto:[email protected]>] On Behalf Of Martin >>> Vigoureux >>> Sent: 24 November 2015 23:17 >>> To: [email protected] <mailto:[email protected]> >>> Subject: Re: [bess] Introducing a one-implementation >>> requirement before WG >>> last calls >>> >>> Hi Adrian, >>> >>> indeed, minutes should have been available sooner. >>>situation >>> has been >>> corrected. >>> >>> The basic motivation for this is simply to avoid >>> (over)loading the iesg >>> with documents that have no (and could possibly never >>> have an) >>> implementation. Or, at least, if every spec gets >>> implemented, it is to >>> prioritize them. >>> >>> The discussion happened at the beginning of the meeting. It >>> was on one >>> of the slides I have presented as part of the WG status. >>> >>> -m >>> >>> Le 24/11/2015 17:07, Adrian Farrel a écrit : >>> >>> Hi Thomas, >>> >>> It's really hard to enter this discussion with any >>> context. >>> >>> Could you post the minutes from the meeting and maybe >>> summarise the points >>> >>> in >>> >>> favour of this approach? >>> (Of course, I can listen to the audio when I have some >>> spare time.) >>> >>> Thanks, >>> Adrian > > >__________________________________________________________________________ >_______________________________________________ > >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. > >_______________________________________________ >BESS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
