Hi Tom,
I believe that I have addressed all of your concerns in the following
revision:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-22
tcp-flags is named flags because their base identity is tcp and the
redundancy of naming is removed.
I will make sure that all of the five I2NSF YANG data model drafts are
well-synchronized.
If you have something to improve, please let me know.
Thanks.
Best Regards,
Paul
On Wed, Jan 12, 2022 at 9:55 PM t petch wrote:
> Hi Paul!
> (adding I2NSF and document alias like an official response to a
> directorate review)
>
> Thanks for this review. A response below and the authors/WG can correct
> me.
>
>
>
> Chipping in as a WG member, my words of 2021 (2022, 2023...) are
> coherence and silos.
>
> This I-D is one of a set of five, or more, which have a lot in common.
> 'Improve' one and the risk is that the set as a whole becomes
> incoherent. I put some effort in in 2021 to reduce the incoherence so I
> am twitchy about the nature of the IETF, operating in silos, the
> different parts bringing incoherence back in again.
>
> Thus there is a comment about POP3 +/- POP3S. POP3 occurs in three I-D
> so change one and IMHO the others have to be changed.
>
> url-capability appears in several I-D. Change one and the other uses of
> it need changing.
>
> tcp-flags already appears in another I-D so here I think that changing
> tcp to tcp-flags would be beneficial.
>
> And so on.
>
> Ideally, as I said about a Genart review, reviewers should be required
> to review the whole set, especially YANG Doctors, but I won't hold my
> breath.
>
> Digging down, there is so much that ought to be in a common I-D, be that
> terminogy, YANG module or whatever but the time for that was several
> years ago, such as 6July 2019 when the WG produced a Terminology I-D.
>
> Tom Petch
>
> >> -Original Message-
> >> From: secdir On Behalf Of Paul Wouters
> >> Sent: Monday, November 29, 2021 4:06 PM
> >>
> >> Note to tools team: I was assigned
> draft-ietf-i2nsf-capability-data-model,
> >> although I had already reviewed the -16 version. I did a review now of
> the -21
> >> version but did not see a way within datatracker to update the review.
> So I
> >> opted to use the secdir mailing list for now.
> >>
> >> Paul
> >>
> >> I have reviewed this document as part of the security directorate's
> ongoing
> >> effort to review all IETF documents being processed by the IESG. These
> >> comments were written primarily for the benefit of the security area
> directors.
> >> Document editors and WG chairs should treat these comments just like any
> >> other last call comments.
> >>
> >> The summary of the review is Has Issues
> >>
> >> I have reviewed the document. I don't have any particular security
> concerns,
> >> and the Security Considerations section is fine. I do have some
> questions/issues
> >> from reading the document.
> >>
> >> I am a bit confused about this part:
> >>
> >> | | +--rw ipv4-capability* identityref
> >> | | +--rw ipv6-capability* identityref
> >> | | +--rw icmpv4-capability* identityref
> >> | | +--rw icmpv6-capability* identityref
> >> | | +--rw tcp-capability*identityref
> >> | | +--rw udp-capability*identityref
> >>
> >> There is an item for v4 and v6 support. Why is there a split of icmpv4
> and
> >> icmpv6?
> >> Why isn't that done similarly to tcp and udp that don't have v4/v6
> versions?
>
> This modeling choice was made because ICMPv4 and ICMPv6 are not the same
> protocol. TCP and UDP are the same protocol regardless of whether they
> are using IPv4 or v6.
>
> >> This term seems to be rather generic:
> >>
> >> | | +--rw url-capability*identityref
> >>
> >> Perhaps what is meant is url-filtering-capability or
> url-protection-capability ?
>
> I'll leave it up to the WG to decide if they want to scope it as such.
>
> >> It also seems rw advanced-nsf-capabilities is really either "rw
> protection-nsf-
> >> capabilities" or "rw filtering-nsf-capabilities" ? It seems "advanced"
> is a very
> >> generic term? It could be useful to allow for further
> non-filter/non-protective
> >> options, but it does seem right now this "advanced" category really
> means
> >> some kind of "client protection" category.
>
> There is a history in the naming convention of advanced vs.
> generic-nsf-capabilities. Advanced capabilities were initially
> extension points discussed in other documents. After refinement, the
> work didn't evolve this way. The WG has discussed and modified this
> convention, and arrived at roughly the explanation documented in Section
> 5.1:
>
> ==[ snip ]==
> In this
> document, two kinds of condition capabilities are used to classify
> different capabilities of NSFs such as generic-nsf-capabilities and
> advanced-nsf-capabilities. First, the generic-nsf-capabilities
> define NSFs that
