All, I agree with Satoru. The Spring WG should be a central place to review the SR related work at DMM and the other WGs.
Thanks Regards … Zafar On 3/23/18, 6:01 AM, "spring on behalf of Satoru Matsushima" <spring-boun...@ietf.org on behalf of satoru.matsush...@gmail.com> wrote: Hello SPRING folks, Let me share an ongoing work in DMM WG that makes SRv6 to be able to provide mobility management path on user plane: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane So please count it when you consider rechartering. But it doesn’t mean that SPRING WG is required to work on mobility management itself. That’s the DMM role. The SRv6 for mobile user plane draft is going to define SRv6 end function variations to support required mobility user plane functions. For sure that we need responsible authority for SRv6 that review those variations to keep the consistency. So we’d expect that in SPRING WG charter. Best regards, --satoru > 2018/03/05 16:59、bruno.decra...@orange.comのメール: > > Hello WG, > > now that nearly all the core documents are in the hands of IESG or beyond, we think it is time to (re)discuss rechartering. > We brought up that question few meetings ago and the feedback, at that time, was that the WG at least needs to be maintained to discuss the extensions following deployment feedback. > > But we need also identify technical directions. > > In order to initiate the discussion we are proposing some high level items but we'd like to make clear a few points before: > * these are only proposals; what might end-up as the next steps for SPRING will be what the WG is willing to work on (which includes having cycles for that). > * what the WG might be rechartered to do is not necessarily limited to that; so other proposals are welcome. > > So, we thought of the following: > > * general architectural work / extensions > there are still few items on our plate and we expect that some might need to be progressed, and we should maybe allow for others to come. > > * service chaining > last meeting there were proposals discussed in SPRING to realize some form of service chaining. any work in that space would require close coordination with SFC and maybe other WG. > > * yang > we are a bit behind here and there is definitely work to do. > > > So please comment on these and propose additional items. > > We'll likely have a dedicated slot in London but we'd like to progress before that. > > Thank you, > --Martin, Rob, Bruno > >> -----Original Message----- >> From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] >> Sent: Wednesday, March 29, 2017 4:25 PM >> To: spring@ietf.org >> Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) >> Subject: Next steps for SPRING? >> >> WG, >> >> in the session we have opened the discussion on the future of the WG, >> putting all options on the table (recharter/close/sleep). >> As a foreword, we still have few WG Documents that we need to -and will- >> push towards IESG (and a greater number that need to reach RFC status), >> but with those we'll have reached most if not all of our milestones, >> thus the question on what's next. >> >> So, we think we have heard during the session that closing wasn't >> desired and one reason for that is to have a home to share and discuss >> deployment considerations as the technology gets deployed. >> There are also a few individual documents knocking at the door, and some >> of them were presented during the session. >> >> To reach out to everyone, we are thus asking the question on the list. >> We would like to hear from you all what the working group should be >> focussing on. >> >> Note, the expectation is that future items should not be use-cases but >> rather be technology extensions/evolutions. >> >> Thank you >> >> Martin & Bruno > > _________________________________________________________________________________________________________________________ > > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring