We (the chairs) discussed what to do with the milestones. The existing
Wiki already shows what drafts have request adoption and requested last
call. The datatracker already shows what has been adopted. Trying to
list specific topics we "want" to work on seems counter-productive,
since the actual answer is "the things which fall within chart and to
which the WG is prepared to apply energy." Judging the later part of
that is what the lengthy text (which will be added to the policy page of
the wiki if the chart is approved) tells everyone. If the WG changes
the basis for judging such energy, then the wiki page will be updated.
This is, after all, the job of the chairs to judge.
We considered putting each draft that we agreed to adopt onto the
milestones list. But concluded that was redundant and unlikely to help
anyone? Would it really help the IESG for us to list all of the topcis
for which we have currently adopt drafts? Remember, we are doing this
recharter largely to clarify the relationship with srv6ops. Not because
we want to change our scoping.
Yours,
Joel
On 11/20/2024 7:54 PM, John Scudder via Datatracker wrote:
John Scudder has entered the following ballot position for
charter-ietf-spring-02-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-spring/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
This sentence makes my brain hurt, simply because the syntax requires way too
much parsing:
Any modification of -or extension to- existing architectures, data
planes, or control or management plane protocols should be carried
out in the WGs responsible for the architecture, data plane, or
control or management plane protocol being modified and in
coordination with the SPRING WG, but may be done in SPRING WG after
agreement with all the relevant WG chairs and responsible Area
Directors.
(Also, the "-or extension to-" thing is just wrong, turn those dashes into
commas, if that text is kept. There are some definite articles missing and
stuff, too.)
I don't have a fantastic rewrite to offer, but a first attempt might be to
break it into several smaller sentences, as in,
Any modification of, or extension to, existing architectures, data
planes, or control or management plane protocols should be carried
out in the WGs responsible for the same. The responsible WG should
coordinate with the SPRING WG. Alternatively, the work may be done in
the SPRING WG after agreement with all the relevant WG chairs and
responsible Area Directors.
I'll be interested in the response to Roman's BLOCK, and I want to echo his
implicit "why aren't any milestones listed?"
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
