Hey Ruediger, Our agreement may be so complete that we may get mistaken for each other in the corridor.
Using a different name for different things is wise. Of course, using a different name for the same thing is not so clever :-) So digging a little to make sure we know what each group is talking about will still be helpful. "Policy based routing" is a broad term with a long history, but "Spring policy routing" is fine. That said, the definition of "Spring policy routing" could also do with some extra help: draft-filsfils-spring-segment-routing-policy has just 5 lines (section 8.7) on "Policy-based Routing" and if that is synonymous with "Spring policy routing" then more words are needed. All I am saying is that as we do the rechartering we need to be clear what we are planning to work on rather than just adding a buzz word or two to the charter. My reasoning is that we want to focus on doing the work and not accidentally throw the door open to everyone who can claim that their idea fits within the undefined term. Adrian > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 22 March 2018 13:36 > To: [email protected]; [email protected] > Subject: AW: [spring] What is "TE" and the rechartering discussion > > Hi Adrian, > > that's a fair proposal, I think. In addition, it may help to avoid the term "Traffic > Engineering" when rechartering Spring. Spring needs to recharter now. I didn't > see any emails on the list which advised against Spring policy routing and the > related OAM mechanisms as future work items. > > Regards, > > Ruediger > > -----Ursprüngliche Nachricht----- > Von: spring [mailto:[email protected]] Im Auftrag von Adrian Farrel > Gesendet: Donnerstag, 22. März 2018 14:08 > An: [email protected] > Betreff: [spring] What is "TE" and the rechartering discussion > > There *might* be some disconnect between: > - What TEAS means by "TE" > - What TEAS is perceived to mean by "TE" > - What Spring means by "TE" > - What Spring is perceived to mean by "TE" > > An option (although it would slow the discussion a bit - it might speed it in the > long term) would be to try to clarify these points with a draft or a joint discussion > session. > Of course, that MUST NOT delay or derail the development of protocol > specifications, but I think the discussion about where work should be done is a > distraction: until that decision has been made (by the chairs and ADs) we should > write drafts and we should discuss them on any and all mailing lists where people > lurk who could help us get the work right. > > Adrian > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
