[savnet] Re: Tommy Jensen's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)

[Lancheng <[e-mail]>]

Hi Tommy,

We think your concern about Section 5.6 is reasonable. The previous text in Section 5.6 was too general and was not intended to describe a specific vulnerability that new intra-domain SAV mechanisms need to address. We would like to clarify that this document does not introduce new security considerations.

Since Section 5.6 does not provide a requirement specific to intra-domain SAV, we plan to remove Section 5.6 in the next version of the draft:
https://github.com/SAVNET-ProblemStatement-Architecture/Intra-domain-problem-statement/commit/eb11bb88f60d9b19649cfabc59985eb0a77c4869

Could this revision address your concern about Section 5.6?

Best regards,
Lancheng and co-authors


> -----Original Messages-----
> From: Lancheng <[e-mail]>
> Send time:Friday, 17/04/2026 13:21:28
> To: "Tommy Jensen" <[e-mail]>
> Cc: "The IESG" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
> Subject: Re: [savnet] Tommy Jensen's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)
> 
> Hi Tommy,
> 
> Thank you for your review.
> 
> After re-evaluating the "vulnerability prevention" requirement, we agree that the current wording is too general and not specific to SAV mechanisms. We therefore believe that retaining this requirement may introduce ambiguity without providing clear, actionable requirement specific to SAV mechanisms.
> 
> We plan to remove this requirement in the next revision.
> 
> Best,
> Lancheng and co-authors
> 
> 
> > -----Original Messages-----
> > From: "Tommy Jensen via Datatracker" <[e-mail]>
> > Send time:Thursday, 16/04/2026 14:03:40
> > To: "The IESG" <[e-mail]>
> > Cc: [e-mail], [e-mail], [e-mail], [e-mail]
> > Subject: [savnet] Tommy Jensen's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)
> > 
> > Tommy Jensen has entered the following ballot position for
> > draft-ietf-savnet-intra-domain-problem-statement-23: Discuss
> > 
> > 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.)
> > 
> > 
> > Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> > for more information about how to handle DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > One sentence summary: I would like to discuss why the authors and WG believe
> > this needs to be published as an RFC, and if that results in a good reason to
> > do so, how the current hand waving of security requirements can be improved.
> > 
> > I echo what other ADs are raising. In my experience, WGs do well with having
> > their own requirements document with WG consensus but not publishing as an RFC.
> > For example, add and deleg both took this approach. It would save going through
> > the much more stringent bar of IESG review over what the WG knows they need to
> > define success amongst themselves for future documents.
> > 
> > However, I am reviewing as if there are good reasons to publish as an RFC that
> > I'm not aware of. As such, I want to bring up the same bit Roman did, which
> > jumped out at me:
> > 
> > >   Any new intra-domain SAV mechanism MUST NOT introduce additional
> > >   security vulnerabilities to existing intra-domain architectures or
> > >   protocols.
> > 
> > As a WG document, I would say this is underspecified but maybe the WG knows
> > what they mean. As an RFC, I do not think this is appropriate at all. Combining
> > this with the Security Considerations that says this introduces no new
> > considerations and I do not think this document says much that is meaningful to
> > people outside your very specific context. It's possible some of this may be
> > obvious to your WG even if not written down because of context for terminology
> > (i.e. "vulnerability" means something specific like "attack surface represented
> > by the presence of a node" to say "MUST NOT introduce additional hops to
> > existing..."). If so, that needs to be defined here, as it currently could be
> > interpreted as "MUST NOT introduce the potential for CVEs" or a number of other
> > things that are quite difficult to mandate normatively.
> > 
> > For an example of how security considerations can still apply to a requirements
> > document, check out Section 4 of the add WG's requirements document (which is
> > what their Security Considerations section links to):
> > https://datatracker.ietf.org/doc/html/draft-ietf-add-requirements-00
> > 
> > All this becomes non-applicable if this is a document the WG writes for
> > themselves, setting aside that then my review isn't needed anyway, because
> > there's some wiggle room for WGs to "know what they meant" since the WG itself
> > can shift its take on requirements as work on drafts meeting those requirements
> > proceeds. This isn't a flexibility given once it is published as an RFC however.
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > No additional commentary; I do not wish to waste the authors' time fine tuning
> > the document since I think this document is probably reasonable as WG
> > self-guidance for to measure how their drafts meet these requirements as it is.
> > I highly encourage consideration of not publishing this as an RFC.
> > 
> > 
> > 
> > -- 
> > savnet mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]