Zafar, I intentionally left the list of milestones out of the mail. Clearly, we need to agree the areas of work before we can break this down into milestones. Equally, we have more flexibility in defining these since they do not need to be reviewed by the IESG.
On Wed, Jun 6, 2018 at 12:14 PM Zafar Ali (zali) <zali= [email protected]> wrote: > > > At IETF101, you and Bruno presented a slide based on the WG feedback on > the mailing list ( > https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01). > During the Spring meeting, the WG agreed to add milestones to those items. > In general, I see some milestones are not included in the proposed > chartered text. > > > > Specifically, multicast in SR is included in that list with the "Ingress > replication SID (Tree SID /spray)" bullet (and support during the WG > meeting) but is missing in the proposed charter text. So, I agree with > Xiejingrong and Michael highlighting the same. There is already interest > and agreement shown by the WG to include multicast in SR in the charter. > This list was a recap of what had been discussed on the mailing list. It was not the proposed exhaustive list. The preference in the charter text (after much discussion) is to ensure that SPRING has a set of focus areas to work on. This does not preclude interested individuals doing other work - and even bringing it to SPRING. We can change the charter in the future if new work comes up that isn't within the charter. I would point out that the narrow scope that we (the SPRING WG) initially had to deliver on has taken almost five years since we initially discussed it (see this thread <https://www.ietf.org/mail-archive/web/status/current/msg00242.html> regarding chartering STATUS as it was at the time). In this period of time, real deployments of SR have happened, and the standards that they rely on have not yet been published. This is unfortunate for those that have shipping implementations, or are relying on behaviours in their network. I'd encourage us to focus on defining the problem spaces that are most important and then work on those, deliver a standard, and then move on to the next area. We can usually determine the importance/relevance of the work to networks based on the number of interested parties - so the intention of the list in the charter is to capture those elements which we perceived to have widest interest in the charter. At some point, there will be a line that is either "in the charter" or not, and some things below it at the current time - yes, that might mean that one's favourite SR application is not currently in the charter, but if there is significant discussion on the list, and work items being brought as individual drafts, we can always address this with Martin. Thanks, r. >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
