Re: [spring] Updating the SPRING WG Charter

[Rob Shakir <[e-mail]>]

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=
[e-mail]> 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.

>