I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-32
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-07-19
|
Jenny Bui | Posted related IPR disclosure Research & Business Foundation Sungkyunkwan University's Statement about IPR related to draft-ietf-i2nsf-capability-data-model | |
2022-06-21
|
Jenny Bui | Posted related IPR disclosure Research & Business Foundation Sungkyunkwan University's Statement about IPR related to draft-ietf-i2nsf-capability-data-model | |
2022-05-26
|
32 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-05-26
|
32 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2022-05-25
|
32 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-05-24
|
32 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2022-05-23
|
32 | (System) | IANA Action state changed to Waiting on ADs from Waiting on RFC Editor |
2022-05-23
|
32 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-32.txt |
2022-05-23
|
32 | Jaehoon Paul Jeong | New version accepted (logged-in submitter: Jaehoon Paul Jeong) |
2022-05-23
|
32 | Jaehoon Paul Jeong | Uploaded new revision |
2022-05-21
|
31 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-05-21
|
31 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-05-16
|
31 | (System) | RFC Editor state changed to MISSREF |
2022-05-16
|
31 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-05-16
|
31 | (System) | Announcement was received by RFC Editor |
2022-05-16
|
31 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-05-16
|
31 | (System) | IANA Action state changed to In Progress |
2022-05-16
|
31 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-05-16
|
31 | Cindy Morgan | IESG has approved the document |
2022-05-16
|
31 | Cindy Morgan | Closed "Approve" ballot |
2022-05-16
|
31 | Cindy Morgan | Ballot approval text was generated |
2022-05-16
|
31 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2022-05-14
|
31 | (System) | Removed all action holders (IESG state changed) |
2022-05-14
|
31 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-05-14
|
31 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-31.txt |
2022-05-14
|
31 | (System) | New version approved |
2022-05-14
|
31 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-05-14
|
31 | Jaehoon Paul Jeong | Uploaded new revision |
2022-05-13
|
30 | Roman Danyliw | Please revise per https://mailarchive.ietf.org/arch/msg/i2nsf/Ugt9NibICeJxgSlyDWgQBJasud0/ |
2022-05-13
|
30 | (System) | Changed action holders to Susan Hares, Robert Moskowitz, Jaehoon Paul Jeong, Qiushi Lin, Jinyong Kim (IESG state changed) |
2022-05-13
|
30 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::AD Followup |
2022-04-16
|
30 | Paul Wouters | [Ballot comment] The latest version addresses the specific concerns that originated from Ben's DISCUSS. Ben's thoughts about a wider discussion are not something that I … [Ballot comment] The latest version addresses the specific concerns that originated from Ben's DISCUSS. Ben's thoughts about a wider discussion are not something that I think would be prudent to discuss at this point in time. |
2022-04-16
|
30 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss |
2022-04-13
|
30 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-30.txt |
2022-04-13
|
30 | (System) | New version approved |
2022-04-13
|
30 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-04-13
|
30 | Jaehoon Paul Jeong | Uploaded new revision |
2022-03-25
|
29 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-29.txt |
2022-03-25
|
29 | (System) | New version approved |
2022-03-25
|
29 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-03-25
|
29 | Jaehoon Paul Jeong | Uploaded new revision |
2022-03-24
|
28 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing my discuss points. |
2022-03-24
|
28 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2022-03-24
|
28 | Paul Wouters | [Ballot discuss] Per AD turn-over, I am pickup up Ben Kaduk's DISCUSS position |
2022-03-24
|
28 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2022-03-24
|
28 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-28.txt |
2022-03-24
|
28 | (System) | New version approved |
2022-03-24
|
28 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-03-24
|
28 | Jaehoon Paul Jeong | Uploaded new revision |
2022-03-23
|
27 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-27.txt |
2022-03-23
|
27 | (System) | New version approved |
2022-03-23
|
27 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-03-23
|
27 | Jaehoon Paul Jeong | Uploaded new revision |
2022-03-19
|
26 | Benjamin Kaduk | [Ballot discuss] In updating my ballot position for the -26 I am mostly just taking the position from the -25 and trimming things that no … [Ballot discuss] In updating my ballot position for the -26 I am mostly just taking the position from the -25 and trimming things that no longer apply. I do, however, still feel that it is most important to have a conversation about what the actual goals of the model are in terms of what type of semantics we expect to be assigned to the different capabilities that a NSF might claim. Only once that topic is understood would we be in a position to make concrete suggestions for the best way to express those intended semantics in YANG. Thanks for adding a note that the routing header condition capabilities indicates only a core set of IPv6 routing headers, with some (e.g.) deprecated ones being excluded. What is the specific set of core routing headers that are indicated, then? Below appear the DISCUSS section from the -25, modified as described above ========================================================================== The overall structure of this data model seems useful and well described. I also think that the identified "core" set of capabilities to include in this YANG module is a good starting set that will have broad applicability (while still allowing extensibility as needed via standard YANG mechanisms). However, I'd like to have a discussion about whether the individual capabilities are identified and described with sufficient precision so that actual implementations will have identical expctations of semantics and thereby achieve interoperability. Do I have to support both IPv4 flags and TCP control bits in order to claim support for "identity flags"? Do I have to support both UDP and SCTP processing to claim support for "identity length"? Do I have to support both TCP and DCCP processing to claim support for "identity offset"? As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with more precision, but I may be working under flawed assumptions of the usage scenario. The "transformation" capability for egress action seems under-defined as well -- would a NSF claim this capability if it can perform a single type of transformation? What happens if the user wanted a different type of transformation? It is probably most prudent to have a general discussion about what level of detail/precision we are expecting to include in this document, and only then go and modify the corresponding parts of the document to be compatible with that expectation. |
2022-03-19
|
26 | Benjamin Kaduk | [Ballot comment] In updating my ballot position for the -26 I am mostly just taking the position from the -25 and trimming things that no … [Ballot comment] In updating my ballot position for the -26 I am mostly just taking the position from the -25 and trimming things that no longer apply. It is possible that I had some false negatives in trimming and left in some comments that are no longer relevant; my apologies in advance, and please just point out that the comment is already addressed. Below appear the COMMENT section from the -25, modified as described above ========================================================================== Thanks for expanding the security and privacy considerations sections in response to my earlier review; it's much improved. It seems to me that knowing the capabilities of a given NSF is necessary but not sufficient in order to plan out a successful deployment that utilizes those capabilities. In particular, knowledge of where the NSF lies in the (physical or virtual) network topology, or the ability to adjust the topology as needed (as might be done in SDN or with a service-function chaning architecture) is also necessary in order to know which flows could actually be processed by a given NSF. While the specifics of the interaction with network topology are probably out of scope for a data model for NSF capabilities, it still seems like we should mention that there is a need to make this integration, which would ideally be accompanied by a reference to a document that meets that need. Right now the word "topology" appears in this document only once, in the security considerations section (as part of a statement that does not seem to be supported by the rest of the document, no less). [ed. that statement about "topology" got removed in the -26. The core issue described above seems to remain present.] Section 3.1 The set of capabilities provided by a given set of NSFs unambiguously defines the security services offered by the set of NSFs used. [...] This is probably more of a soapbox rant than an actionable comment, but "unambiguously defines" is a very high bar. If there is any kind of vendor differentiation or quality-of-implementation differences, there may be attributes not captured by the set of capabilities that still affect the security services on offer. Section 6 identity device-type { description "Identity for device type condition capability. The capability for matching the destination device type."; Why is the destination device given the unqualified name "device-type"? Why would the source device type not also be of interest? [ed. this got updated to also mention source device type. In a certain sense one might imagine a device having capability to match only one one but not the other, akin to my DISCUSS point, though in this particular case that seems likely to be rare] identity routing-header { base ipv6; description "Identity for IPv6 routing header condition capability"; The semantics of this identity (and several adjacent ones, really) seem rather under-defined. Does this mean that my NSF can recognize that there is a RH present? Or is the NSF expected to do some further parsing on it? Which types of RH would the NSF be required to be able to parse if it indicates this capability? What if new RH types are allocated in the future? identity options { base tcp; description "Identity for TCP options condition capability"; Similarly to the routing-header, what am I signifying if I claim this capability? TCP options are maintained in an IANA registry, so attempting to claim support for all options is an open-ended task. identity transformation { base egress-action; description "Identity for transformation action capability"; Keeping with the theme, "transformation" is a very generic capability. In some cases the nature of the transformations that are or are not possible will be very important to the user, but in this model an NSF has to either claim the "transformation" capability or not claim it, leaving no room for the subtleties that will be very important for actual deployments. |
2022-03-19
|
26 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2022-02-10
|
26 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2022-02-10
|
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-02-10
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-02-10
|
26 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-26.txt |
2022-02-10
|
26 | (System) | New version approved |
2022-02-10
|
26 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-02-10
|
26 | Jaehoon Paul Jeong | Uploaded new revision |
2022-02-08
|
25 | Éric Vyncke | Request closed, assignment withdrawn: Pascal Thubert Telechat INTDIR review |
2022-02-08
|
25 | Éric Vyncke | Closed request for Telechat review by INTDIR with state 'Withdrawn': Telechat deadline has passed... The document has been approved by the IESG. Please next time, … Closed request for Telechat review by INTDIR with state 'Withdrawn': Telechat deadline has passed... The document has been approved by the IESG. Please next time, be explicit and refuse to review the document. Thank you. -éric |
2022-02-03
|
25 | (System) | Changed action holders to Susan Hares, Roman Danyliw, Robert Moskowitz, Jaehoon (Paul) Jeong, Qiushi Lin, Jinyong Kim (IESG state changed) |
2022-02-03
|
25 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-02-03
|
25 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2022-02-03
|
25 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-02-03
|
25 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-02-03
|
25 | Zaheduzzaman Sarker | [Ballot discuss] Thanks for working on this data-model. It seems useful specification to have. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request … [Ballot discuss] Thanks for working on this data-model. It seems useful specification to have. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I would like to discuss the followings 1. With RFC9000 and live traffic in the Internet it feels a bit odd to not mention QUIC as transport protocol. I initially thought it might have been part of UDP identity and capabilities. However, could not reason with that take as there will QUIC and UDP traffic mix and treating them same will not be the correct approach. I also think I am not the first one to notice that QUIC is missing and it might have been excluded with proper thoughts. In that case I would like to know more about it. 2. With live 5G networks, a similar observation as above for "voip-volte-phone" identity and "voip-volte-filtering" identity. The term 'volte' makes this identity very much specific to a particular cellular network generation, LTE (4G). Even though the same network infrastructure for 'volte' can be and will be used to enable 5G voice, I didn't understood the reasoning behind a 'volte' specific identity and filtering. Was this intentional and the idea is to extend the data-model for all the cellular network generations when needed? I think the need is already now. Alternative would be to have the identity and filtering independent of cellular network generation. Has this been considered? 3. I am not sure the high level of HTTPS identity and capabilities definition is good enough? We have multiple generations of HTTP and underlying transport protocol for those generations are not same, neither allows same kind of operations to be performed. for example, HTTP2 over TCP/TLS , with might allow termination of TLS context by the intermediaries, will not be true for HTTP3 over QUIC. I understand that the actual policy and conflict resolution is out of scope of this specification. However, I could not resist myself to think about a case where a policy rule may allow HTTPS traffic but blocks general UDP traffic. This would mean that HTTPS traffic with QUIC as transport protocol will be blocked, which might not be the intention at all. (Note that if QUIC traffic is blocked the clients will fall back to TCP/TSL as transport protocol(s).) I believe to be more functional the general HTTPs capabilities and rule need to be more granular and specific to HTTP generations. What is the thinking here? |
2022-02-03
|
25 | Zaheduzzaman Sarker | [Ballot comment] I had noticed couple of reference issues, those were also picked up by Martin and Francesca. I see the authors have already take … [Ballot comment] I had noticed couple of reference issues, those were also picked up by Martin and Francesca. I see the authors have already take care of those. Thanks for being prompt. |
2022-02-03
|
25 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2022-02-03
|
25 | Lars Eggert | [Ballot comment] DOWNREF [RFC8329] from this Proposed Standard to Informational RFC8329. Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) … [Ballot comment] DOWNREF [RFC8329] from this Proposed Standard to Informational RFC8329. Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/RZKBK7ht9PrmIMC5VpMwaLohkc4). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". "Table of Contents", paragraph 2, nit: > Registration for the Capabilities of a HTTP and HTTPS Flood Mitigator . . . > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". (Also elsewhere.) Section 1. , paragraph 2, nit: > tomers. Multiple NSFs can be combined together to provide security services > ^^^^^^^^^^^^^^^^^ "combined together" is redundant. Use "combined". Section 3.1. , paragraph 3, nit: > , respectively. These facilitate multi-vendor interoperability. * Automation: > ^^^^^^^^^^^^ This word is normally spelled as one. Section 3.1. , paragraph 10, nit: > r values in order to determine whether or not the set of actions in that (im > ^^^^^^^^^^^^^^ Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Section 3.1. , paragraph 22, nit: > firewall R2: During 7am-8pm, run anti-virus There is no conflict between the > ^^^^^^^^^^ This word is normally spelled as one. (Also elsewhere.) Section 6. , paragraph 156, nit: > er-id or user-name. The users can collected into a user-group and identified > ^^^^^^^^^ The modal verb "can" requires the verb's base form. Section 6. , paragraph 169, nit: > f the capabilities may entail privacy sensitive information as explicitly out > ^^^^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. (Also elsewhere.) Document references draft-ietf-i2nsf-nsf-monitoring-data-model-12, but -14 is the latest available revision. Document references draft-ietf-i2nsf-nsf-facing-interface-dm-16, but -20 is the latest available revision. Document references draft-ietf-i2nsf-registration-interface-dm-13, but -14 is the latest available revision. |
2022-02-03
|
25 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2022-02-02
|
25 | Erik Kline | [Ballot comment] [S10.2; question] * Should all of OODMP, OODOP, & OODSRP point to the "mediator-pattern" URL? Seems like: * OODOP -> … [Ballot comment] [S10.2; question] * Should all of OODMP, OODOP, & OODSRP point to the "mediator-pattern" URL? Seems like: * OODOP -> https://www.oodesign.com/observer-pattern.html and * OODSRP -> https://www.oodesign.com/single-responsibility-principle.html is perhaps more appropriate. [S6; comment] * RFC 8805 was published on the ISE stream, and is probably not suitable as normative reference (as an Informational reference that seems okay to me). |
2022-02-02
|
25 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-02-02
|
25 | Benjamin Kaduk | [Ballot discuss] The overall structure of this data model seems useful and well described. I also think that the identified "core" set of capabilities to … [Ballot discuss] The overall structure of this data model seems useful and well described. I also think that the identified "core" set of capabilities to include in this YANG module is a good starting set that will have broad applicability (while still allowing extensibility as needed via standard YANG mechanisms). However, I'd like to have a discussion about whether the individual capabilities are identified and described with sufficient precision so that actual implementations will have identical expctations of semantics and thereby achieve interoperability. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with more precision, but I may be working under flawed assumptions of the usage scenario. Consider the resolution strategies as an example. "First Matching" and "Last Matching" are pretty straightforward, but where can I find a precise specification of "Prioritized Matching Rule with Errors" or "Prioritized Matching Rule with No Errors"? I don't think I can find one in this document, and I don't see any references given that would settle the question either. Similarly, if an NSF indicates the "routing-header" capability, what specifically does that mean? IPv6 routing headers are managed in an IANA registry and this registry is seeing some recent activity, with SRH being registered in 2020 and two CRH variants given temporary registrations in 2021. Is it required to support all defined routing headers in order to claim this capability? Is that all headers defined at the time of this writing, or at the time the claim is being made, or some other definition of "all"? Is it required to support deprecated routing header types like source route ("RH0") and Nimrod? If it suffices to only support any single routing header type, then this is no longer an unambiguous description of the feature. As a couple more examples that I called out in my COMMENT section below, support for HTTP will likely vary across major version of HTTP, and the "transformation" capability for egress action seems under-defined as well -- would a NSF claim this capability if it can perform a single type of transformation? What happens if the user wanted a different type of transformation? It is probably most prudent to have a general discussion about what level of detail/precision we are expecting to include in this document, and only then go and modify the corresponding parts of the document to be compatible with that expectation. |
2022-02-02
|
25 | Benjamin Kaduk | [Ballot comment] Thanks for expanding the security and privacy considerations sections in response to my earlier review; it's much improved. It seems to me that … [Ballot comment] Thanks for expanding the security and privacy considerations sections in response to my earlier review; it's much improved. It seems to me that knowing the capabilities of a given NSF is necessary but not sufficient in order to plan out a successful deployment that utilizes those capabilities. In particular, knowledge of where the NSF lies in the (physical or virtual) network topology, or the ability to adjust the topology as needed (as might be done in SDN or with a service-function chaning architecture) is also necessary in order to know which flows could actually be processed by a given NSF. While the specifics of the interaction with network topology are probably out of scope for a data model for NSF capabilities, it still seems like we should mention that there is a need to make this integration, which would ideally be accompanied by a reference to a document that meets that need. Right now the word "topology" appears in this document only once, in the security considerations section (as part of a statement that does not seem to be supported by the rest of the document, no less). Section 1 * Definition for resolution strategy capabilities of network security functions. I didn't see discussion of the need for resolution strategies in the framework (maybe I missed it), so we might want to have a bit of exposition on how the need for it arises due to the other elements of the framework and deployment reality. Some of that content is already present down in §3.2, but there doesn't seem to be an introductory remark that this is extending past what the framework envisioned. Section 3.1 * Automation: The system MUST have the ability to auto-discover, auto-negotiate, and auto-update its security capabilities (i.e., without human intervention). These features are especially useful I assume that "auto-update" here is in the sense of "keep the central database of NSF capabilities current" rather than "go fetch and apply software patches". If my assumption is correct, then we might refer to its "capability registration", admittedly at the cost of the alliterative "auto-"s. of capabilities that other I2NSF Components can use. These capabilities MUST have their access control restricted by a policy; this is out of scope for this document. [...] Is the mechanics of the access control, the policy about which components are granted which access, or both, what is out of scope? The set of capabilities provided by a given set of NSFs unambiguously defines the security services offered by the set of NSFs used. [...] This is probably more of a soapbox rant than an actionable comment, but "unambiguously defines" is a very high bar. If there is any kind of vendor differentiation or quality-of-implementation differences, there may be attributes not captured by the set of capabilities that still affect the security services on offer. Technically, the "Policy Rule" is really a container that aggregates the above three clauses, as well as metadata, which describe the characteristics and behaviors of a capability (or an NSF). Almost nit-like, but up here since it actually affects meaning: if the thing that describes the characteristics and behaviors of a capability/NSF is the metadata, then remove the comma after "metadata". Aggregating metadata enables a business logic to be used to prescribe a behavior. For example, suppose a particular ECA Policy Rule contains three actions (A1, A2, and A3, in that order). Action A2 has a priority of 10; actions A1 and A3 have no priority specified. This is the first time we've mentioned "priority"; it is not a good way to introduce the topic. In fact, this paragraph is the only place that the word "priority" appears in the document (though "prioritized" does appear in §5.1 and in the YANG model ... with no further description of how to fulfil them). Also, is the concept of being able to aggregate multiple pieces of metadata the importent point here, or just the ability to associate metadata with a policy at all? I might rephrase slightly to use "associate" in that case. Section 3.2 There is no conflict between the two policy rules R1 and R2, since the actions are different. [...] I don't think the actions just being "different" is enough to meet the definition. Is the intent to say that they act on different *objects*, or that somehow they act on the same object "in the same way"? * Resolution Strategies: They can be used to specify how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF; I'm kind of curious how a conflict would arise between the actions of "the same policy rule". Isn't that just a badly written rule? (There is similar text in §5, if any change is made here.) Section 4 Controller. As described in [RFC8192], with the usage of Registration Interface and the YANG module in this document, the NSFs manufactured by multiple vendors can be managed together by the Security Controller in a centralized way and be updated dynamically by each vendor as the NSF has software or hardware updates. As above, please clarify what is being updated in the scenario being referred to (i.e., software on the device vs the registration information at the security controller). v I2NSF +-----------------+------------+ Registration +-------------+ | Network Operator Mgmt System | Interface | Developer's | | (i.e., Security Controller) |<------------->| Mgmt System | +-----------------+------------+ +-------------+ ^ New NSF | Cap = {FW, WF} I2NSF | E = {} NSF-Facing Interface | C = {IPv4, IPv6} | A = {Allow, Deny} I still think it would be useful to have some prose indicating that the "E = {}" means that the event boolean will always evaluate to true. Section 6 identity system-event { [...] identity system-alarm { [...] identity time { [...] identity device-type { [...] identity geographic-location { [...] identity directional { All of these identities are used as base identities for other identities. Are any of them intended to also be used directly as their own identifier? If not, then I think the description should use the phrase "base identity". identity device-type { description "Identity for device type condition capability. The capability for matching the destination device type."; Why is the destination device given the unqualified name "device-type"? Why would the source device type not also be of interest? identity fragment-flags { base ipv4; description "Identity for IPv4 fragment flags condition capability"; I'm not aware of "fragment flags" being a common jargon to refer to the 'flags' field of the IPv4 header. identity routing-header { base ipv6; description "Identity for IPv6 routing header condition capability"; The semantics of this identity (and several adjacent ones, really) seem rather under-defined. Does this mean that my NSF can recognize that there is a RH present? Or is the NSF expected to do some further parsing on it? Which types of RH would the NSF be required to be able to parse if it indicates this capability? What if new RH types are allocated in the future? identity sctp { base transport-protocol; description "Identity for SCTP condition capabilities"; [...] identity dccp { base transport-protocol; description "Identity for DCCP condition capabilities"; The TCP and UTP identities said they were "base identity" for the respective condition capabilities. Why are SCTP and DCCP different in this regard? identity options { base tcp; description "Identity for TCP options condition capability"; Similarly to the routing-header, what am I signifying if I claim this capability? TCP options are maintained in an IANA registry, so attempting to claim support for all options is an open-ended task. identity length { base tcp; base udp; description "Identity for matching TCP or UDP length condition capability. Why is SCTP (DATA) chunk length not applicable here? (I don't actually know if DCCP has something analogous.) identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol."; reference "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"; This seems highly problematic. HTTP/1.x, HTTP/2, and HTTP/3 are completely different protocols and a device that can parse one should not be expected to be able to parse any of the others. Trying to conglomerate support for "http" conditions in this manner seems doomed to result in failure. identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3. This includes POP3 over TLS"; [...] identity imap { base application-protocol; description "The identity for Internet Message Access Protocol. This includes IMAP over TLS"; Why are pop3 and imap different from http, which gets distinct identities for http-not-s and https? identity transformation { base egress-action; description "Identity for transformation action capability"; Keeping with the theme, "transformation" is a very generic capability. In some cases the nature of the transformations that are or are not possible will be very important to the user, but in this model an NSF has to either claim the "transformation" capability or not claim it, leaving no room for the subtleties that will be very important for actual deployments. identity fmr { base resolution-strategy; description "Identity for First Matching Rule (FMR) resolution strategy capability"; [...] identity lmr { base resolution-strategy; description "Identity for Last Matching Rule (LMR) resolution strategy capability"; [...] identity pmr { base resolution-strategy; description "Identity for Prioritized Matching Rule (PMR) resolution strategy capability"; [...] identity pmre { base resolution-strategy; description "Identity for Prioritized Matching Rule with Errors (PMRE) resolution strategy capability"; [...] identity pmrn { base resolution-strategy; description "Identity for Prioritized Matching Rule with No Errors (PMRN) resolution strategy capability"; Where are the details of these resolution strategies specified? "first match" and "last match" are perhaps self-explanatory, but I am confident that just relying on the string "Prioritized Matching Rule with No Errors (PMRN)" with no reference or further explanation will result in divergent implementation. Section 9 * list nsf: The leak of this node to an attacker could reveal the specific configuration of security controls to an attacker. An attacker can craft an attack path that avoids observation or mitigations; one may reveal topology information to inform additional targets or enable lateral movement; one enables the construction of an attack path that avoids observation or mitigations; one provides an indication that the operator has discovered the attack. I don't understand what the "one" in the different clauses here refers to. Is it supposed to be "one node" in the YANG tree? But I don't remember seeing specific nodes that provide these abilities if read access is obtained by an attacker; could we name the specific nodes if that's the case? Also, separately, I don't think any of the nodes in *this* module provide topology information. My understanding is that topolgoy information would have to come from a different source (likely a separate YANG module implemented by the same system) and could be combined with the information from this model in order to perform the indicated attacks. Some of the capability indicators (i.e., identities) defined in this document are highly sensitive and/or privileged operations that inherently require access to individuals' private data. These are subtrees and data nodes that are considered privacy sensitive: [...] I think that url-filtering-capability should also be listed here. Perhaps NEW: % * url-filtering-capability: URLs themselves often contain sensitive % information [CAPABILITY-URLS], and access to URLs typically comes % hand-in-hand with access to request and response content, which is % also often sensitive. % % [CAPABILITY-URLS]: https://www.w3.org/2001/tag/doc/capability-urls/ Section 10.2 I'm not sure what methodology was used to classify references as normative vs informative. E.g., RFC 6691 is cited in the same way that RFC 7323 is, but RFC 7323 is classified as normative and RFC 6691 is classified as informative. For reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ , the classification should be made solely on how the reference is used in the document, with no dependence on the status or source of the referred-to document. For concreteness, I suggest that the classification of RFCs 2818 and 6691, and [I-D.ietf-i2nsf-nsf-facing-interface-dm] and [I-D.ietf-i2nsf-registration-interface-dm] be revisited. [OODMP] "https://www.oodesign.com/mediator-pattern.html". [OODOP] "https://www.oodesign.com/mediator-pattern.html". [OODSRP] "https://www.oodesign.com/mediator-pattern.html". I think the latter two were intended to point to https://www.oodesign.com/observer-pattern.html and https://www.oodesign.com/single-responsibility-principle.html respectively. NITS Section 2 This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA). The meaning of the symbols in tree Please reference RFC 8342 for NMDA. Section 3 This CapIM includes enabling a security controller in an I2NSF framework [RFC8329] to properly identify and manage NSFs, and allow NSFs to properly declare their functionality through a Developer's Management System (DMS) [RFC8329], so that they can be used in the correct way. I think there's a word or two missing between "includes" and "enabling" (perhaps "mechanisms for" or "provision for"?) -- the information model itself does not include an element "enabling a controller to ...", rather, the existince of the model (and other things build on it) enables the controller to do these things. Alternately, drop "includes" and go with "this CapIM enables [...]". Section 3.1 * Advertisement: Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to "The Registration Interface" * Execution: NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring Likewise here, add "The". set of Message Exchange Patterns [Hohpe]. Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] can register the "The" here as well. capabilities of NSFs with the security controller from the request of Developer's Management System providing NSFs and the corresponding security capabilities. Also, this interface can Something seems awry here but I can't pick out the intended meaning so as to suggest a fix. Is the idea that the Developer's Management System instigates a request and as a result of that request the list of relevant NSFs and their respective security capabilities become available at the security controller? If so, a comma before "providing" would help, as would some more description like "providing a list of available ... at the security controller". whether it needs to invoke scaling or not. NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe "The NSF Monitoring Interface" or stored separately in a vendor's local repository. In either case, Registration Interface can facilitate this update process to "the Registration Interface" Developer's Management System to let the security controller update its repository for NSFs and their security capabilities. I think we want s/to Developer's Management System to let/so the Developer's Management System can let/ Section 4 * If a network administrator wants to block IPv4 or IPv6 packets from malicious users, the network administrator sends a security policy rule to block the users to the Network Operator Management System (i.e., Security Controller) using the I2NSF Consumer-Facing Interface. The ordering of the clauses seems wrong here. I think we want to say that the network admin sends a security policy rule to the security controller, and that rule says to block the users in question. So we might consider NEW: % If a network administrator wants to block IPv4 or IPv6 packets % from malicious users, the network administrator sends a security policy % rule to the Network Operator Management System (i.e., Security Controller) % using the I2NSF Consumer-Facing Interface, directing the system to block % the users in question. Section 5.1 The context capabilities provide extra information for the condition. The given context conditions are application filter, target, user condition, and geographic location. The application filter capability is capability in matching the packet based on the application protocol, such as HTTP, HTTPS, FTP, etc. The device type capability is capability in matching the type of the destination devices, such as PC, IoT, Network Infrastructure devices, etc. The user condition is capability in matching the users of the network by mapping each user ID to an IP address. Users can be combined into one group. The geographic location capability is capability in matching the geographical location of a source or destination of a packet. A couple points. The construction of "the capability is capability in " is not grammatical; it would be better as something like "the capability is the capability for" (other variants are possible that change the conjugation of the following verb) (multiple instances). The sentence about "users can be combined into one group" is potentially confusing. Is there only ever one group possible? If there can be multiple concurrent groupings defined, then something like "users can be combined into groups" would be more accurate. In addition, see Section 9.1 (Flow-Based NSF Capability Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about logging at NSFs. s/7.5/6.5/ (at least as of the -12 of the referenced draft) Section 6 identity system-event { base event; description "Identity for system event. System event (called alert) is I suggest adding "sometimes" or "also" at the start of the parenthetical. description "Identity for CPU alarm. CPU is the Central Processing Unit that executes basic operations of the system. A cpu-alarm is emitted when the CPU usage is exceeding the threshold."; [...] description "Identity for disk alarm. Disk is the hardware to store information for a long period, i.e., Hard Disk and Solid-State Drive. A disk-alarm is emitted when the disk usage is exceeding the threshold."; s/the threshold/a threshold/. There is no one single definite threshold that always applies; the threshold in question is either going to be independently configurable or will vary across systems/implementations. identity voip-volte-phone { base device-type; description "Identity for voip-volte-phone"; I think we want "VOIP or VoLTE phone"; there isn't really a single combined VOIP/VoLTE phone as a concept (even if modern premium smartphones do offer seamless wifi/LTE calling). Section 9 * list nsf: An attacker could alter the security capabilities associated with an NSF by disabling or enabling the functionality of the security capabilities of the NSF. I'd suggest NEW: % * list nsf: An attacker could alter the security capabilities % associated with an NSF in the database maintained by the security % controller. Such changes could result in security functionality % going unused due to the controller not having a record of it, and % could also result in falsely claiming security capabilities that the % controller would then attempt to use but would not actually be % provided. |
2022-02-02
|
25 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2022-02-02
|
25 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-02-02
|
25 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. As I reviewed the -12 and as I am running out of time, I … [Ballot comment] Thank you for the work put into this document. As I reviewed the -12 and as I am running out of time, I have focused my ballot on the changes between -12 and -25. Thanks to the authors for including the information model (but see my review :( ...), the document should now have a logical flow from information to data model (this was part of my previous DISCUSS but Susan Hares and Diego Lopez had replied to me on this topic). Thanks as well for handling SCTP now. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Linda Dunbar for the shepherd's write-up including the section about the WG consensus and the IPR declarations, minor regrets: nothing is said about the 2nd IESG evaluation. I hope that this helps to improve the document, Regards, -éric ## Section 3.1 This comment is probably for purists, but I wonder whether the automation & scalability (important operational requirements) should be requirements for an information model (as opposed to a data model). And, the whole 'information model' section is not an information model :-( ... Please rename it as 'requirements' or something like that. ## Section 6 (YANG model) 'identity next-header': the text "Identity for the capability of matching IPv4 Protocol Field or equivalent to IPv6 Next Header.;" does not sound like a proper English sentence to me (I can obviously be wrong as I am not a native English speaker) in the same identity, please use the right wording for the IANA registry (it does not include IPv4 in its name/title) Should "identity identification" be renamed into "identity fragment-identification" ? And also applied to IPv6 as the IPv6 fragmentation extension header has this field ? identity identity fragment-offset: there is a fragment offset field in the IPv6 fragmentation extension header... Does this identity also apply to IPv6 ? should 'identity type' be renamed in icmp-type ? Same applies for 'code' Suggest to s/traffic flow capability/traffic flow export capability/ For consistency, s/identity hop-by-hop/identity hop-by-hop-header/ and s/destination-options/destination-options-header/ I am puzzled by the limited list of application-protocols, i.e., DNS, NTP, ... are not included. Is there a need to have such a non-exhaustive list ? |
2022-02-02
|
25 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-02-02
|
25 | Martin Duke | [Ballot comment] Thanks for addressing my DISCUSS and comments. |
2022-02-02
|
25 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2022-02-02
|
25 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-25.txt |
2022-02-02
|
25 | (System) | New version approved |
2022-02-02
|
25 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-02-02
|
25 | Jaehoon Paul Jeong | Uploaded new revision |
2022-02-01
|
24 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. I only have one minor comment: Please update the references to RFC 7230, RFC … [Ballot comment] Thank you for the work on this document. I only have one minor comment: Please update the references to RFC 7230, RFC 7231 and RFC 2818 with draft-ietf-httpbis-semantics-19 and draft-ietf-httpbis-messaging-19, which will obsolete them. Note that the HTTP drafts are with the RFC Editor in AUTH48, so will not delay publication of your document. Francesca |
2022-02-01
|
24 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2022-02-01
|
24 | Martin Duke | [Ballot discuss] draft-ietf-i2nsf-registration-interface-dm and draft-ietf-i2nsf-nsf-facing-interface-dm are connected to a MUST in Section 3.1 and then listed as informative references. |
2022-02-01
|
24 | Martin Duke | |
2022-02-01
|
24 | Martin Duke | [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke |
2022-01-31
|
24 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-24.txt |
2022-01-31
|
24 | (System) | New version approved |
2022-01-31
|
24 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-01-31
|
24 | Jaehoon Paul Jeong | Uploaded new revision |
2022-01-30
|
23 | Paul Wouters | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Paul Wouters. Sent review to list. |
2022-01-28
|
23 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Paul Wouters |
2022-01-28
|
23 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Paul Wouters |
2022-01-28
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-28
|
23 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-23.txt |
2022-01-28
|
23 | (System) | New version approved |
2022-01-28
|
23 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-01-28
|
23 | Jaehoon Paul Jeong | Uploaded new revision |
2022-01-28
|
23 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-01-28
|
23 | Jaehoon Paul Jeong | Uploaded new revision |
2022-01-26
|
22 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-01-25
|
22 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Pascal Thubert |
2022-01-25
|
22 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Pascal Thubert |
2022-01-25
|
22 | Éric Vyncke | Requested Telechat review by INTDIR |
2022-01-24
|
22 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2022-01-24
|
22 | Cindy Morgan | Created "Approve" ballot |
2022-01-24
|
22 | Cindy Morgan | Closed "Approve" ballot |
2022-01-24
|
22 | Cindy Morgan | Placed on agenda for telechat - 2022-02-03 |
2022-01-24
|
22 | Roman Danyliw | Ballot has been issued |
2022-01-24
|
22 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2022-01-24
|
22 | Roman Danyliw | Ballot writeup was changed |
2022-01-24
|
22 | Roman Danyliw | Ballot approval text was generated |
2022-01-22
|
22 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2022-01-22
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-01-22
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-22
|
22 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-22.txt |
2022-01-22
|
22 | (System) | New version approved |
2022-01-22
|
22 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2022-01-22
|
22 | Jaehoon Paul Jeong | Uploaded new revision |
2022-01-06
|
21 | Roman Danyliw | See IETF LC SECDIR Review: https://mailarchive.ietf.org/arch/msg/i2nsf/gee6PshF774J9GmlQtozwQcIW-4/ |
2022-01-06
|
21 | (System) | Changed action holders to Susan Hares, Roman Danyliw, Robert Moskowitz, Jaehoon (Paul) Jeong, Qiushi Lin, Jinyong Kim (IESG state changed) |
2022-01-06
|
21 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-12-02
|
21 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2021-12-02
|
21 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-12-01
|
21 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version (draft-ietf-i2nsf-capability-data-model-21 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version (draft-ietf-i2nsf-capability-data-model-21) is dated Nov 13, 2021. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines an information model and the corresponding YANG data model for the capabilities of NSFs in the Interface to Network Security Functions (I2NSF) framework to manage the capabilities of the various NSFs centrally. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been IETF Hackathon implementation and Open-source implementation (https://github.com/jaehoonpaul/i2nsf-framework) for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read many versions of this document. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, the YANG model described in the document has reference to RFC8805 which is an Informational RFC. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2021-11-30
|
21 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version (draft-ietf-i2nsf-capability-data-model-21 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version (draft-ietf-i2nsf-capability-data-model-21) is dated Nov 13, 2021. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines an information model and the corresponding YANG data model for the capabilities of NSFs in the Interface to Network Security Functions (I2NSF) framework to manage the capabilities of the various NSFs centrally. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read many versions of this document. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2021-11-29
|
21 | Paul Wouters | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Paul Wouters. |
2021-11-29
|
21 | Michelle Cotton | IANA Experts State changed to Reviews assigned from Expert Reviews OK |
2021-11-29
|
21 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2021-11-29
|
21 | Michelle Cotton | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-21. If any part of this review is inaccurate, please let … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-21. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: yang:ietf-i2nsf-capability URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a single, new YANG module will be registered as follows: Name: ietf-i2nsf-capability File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Prefix: nsfcap Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Michelle Cotton IANA Services |
2021-11-29
|
21 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-11-18
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2021-11-18
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2021-11-15
|
21 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-11-29): From: The IESG To: IETF-Announce CC: Linda Dunbar , draft-ietf-i2nsf-capability-data-model@ietf.org, dunbar.ll@gmail.com, i2nsf-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2021-11-29): From: The IESG To: IETF-Announce CC: Linda Dunbar , draft-ietf-i2nsf-capability-data-model@ietf.org, dunbar.ll@gmail.com, i2nsf-chairs@ietf.org, i2nsf@ietf.org, rdd@cert.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (I2NSF Capability YANG Data Model) to Proposed Standard The IESG has received a request from the Interface to Network Security Functions WG (i2nsf) to consider the following document: - 'I2NSF Capability YANG Data Model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3556/ https://datatracker.ietf.org/ipr/3606/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8805: A Format for Self-Published IP Geolocation Feeds (Informational - Independent Submission) draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF)) draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF Monitoring Interface YANG Data Model (None - Internet Engineering Task Force (IETF)) draft-ietf-i2nsf-registration-interface-dm: I2NSF Registration Interface YANG Data Model (None - Internet Engineering Task Force (IETF)) rfc4766: Intrusion Detection Message Exchange Requirements (Informational - Internet Engineering Task Force (IETF)) |
2021-11-15
|
21 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-11-15
|
21 | Amy Vezza | Last call announcement was generated |
2021-11-14
|
21 | Roman Danyliw | Last call was requested |
2021-11-14
|
21 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-11-13
|
21 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2021-11-13
|
21 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-11-13
|
21 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-21.txt |
2021-11-13
|
21 | (System) | New version approved |
2021-11-13
|
21 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-11-13
|
21 | Jaehoon Paul Jeong | Uploaded new revision |
2021-11-01
|
20 | Roman Danyliw | AD Review (3): https://mailarchive.ietf.org/arch/msg/i2nsf/O06Yf_HCJhA9dvdHJQM1Ae5l22o/ |
2021-11-01
|
20 | (System) | Changed action holders to Susan Hares, Roman Danyliw, Robert Moskowitz, Jaehoon (Paul) Jeong, Qiushi Lin, Jinyong Kim (IESG state changed) |
2021-11-01
|
20 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2021-10-04
|
20 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-20.txt |
2021-10-04
|
20 | (System) | New version approved |
2021-10-04
|
20 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-10-04
|
20 | Jaehoon Paul Jeong | Uploaded new revision |
2021-09-28
|
19 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-19.txt |
2021-09-28
|
19 | (System) | New version approved |
2021-09-28
|
19 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-09-28
|
19 | Jaehoon Paul Jeong | Uploaded new revision |
2021-09-28
|
19 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-09-28
|
19 | Jaehoon Paul Jeong | Uploaded new revision |
2021-09-15
|
18 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-18.txt |
2021-09-15
|
18 | (System) | New version approved |
2021-09-15
|
18 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-09-15
|
18 | Jaehoon Paul Jeong | Uploaded new revision |
2021-08-14
|
17 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2021-08-14
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-08-14
|
17 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-17.txt |
2021-08-14
|
17 | (System) | New version approved |
2021-08-14
|
17 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-08-14
|
17 | Jaehoon Paul Jeong | Uploaded new revision |
2021-08-05
|
16 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/i2nsf/BJ4GUttBVZRvHGm3m2_bEycNQWI/ |
2021-08-05
|
16 | (System) | Changed action holders to Susan Hares, Roman Danyliw, Robert Moskowitz, Jaehoon (Paul) Jeong, Qiushi Lin, Jinyong Kim (IESG state changed) |
2021-08-05
|
16 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2021-07-18
|
16 | Erik Kline | [Ballot comment] Thanks for addressing my various comments. Clearing my discuss. One nit: identity ipv6-geo-ip { base ipv6-capability; description … [Ballot comment] Thanks for addressing my various comments. Clearing my discuss. One nit: identity ipv6-geo-ip { base ipv6-capability; description "Identity for IPv4 geography condition capability"; That should probably be "Identity for IPv6 geography..." |
2021-07-18
|
16 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss |
2021-05-18
|
16 | Paul Wouters | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Paul Wouters. Sent review to list. |
2021-04-27
|
16 | Linda Dunbar | This is the second time that I2NSF WG sent the document to IESG. When I2NSF WG closed the WGLC for draft-ietf-i2nsf-capability-data-model in Dec 2019 ( … This is the second time that I2NSF WG sent the document to IESG. When I2NSF WG closed the WGLC for draft-ietf-i2nsf-capability-data-model in Dec 2019 (https://mailarchive.ietf.org/arch/browse/i2nsf/?q=draft-ietf-i2nsf-capability-data-model&f_from=Linda%20Dunbar ), there was a formative reference to draft-ietf-i2nsf-capability-05 which was stale. After the review, IESG decided to throw the draft back to I2NSF WG and requested the WG to reach the consensus to sunset the draft-ietf-i2nsf-capability-05. The WG finally reached the consensus in Oct 2020 (https://mailarchive.ietf.org/arch/browse/i2nsf/?q=draft-ietf-i2nsf-capability-data-model&f_from=Linda%20Dunbar). The authors have merged all the relevant content from draft-ietf-i2nsf-capability-05 and addressed all the comments from the YANG Doctor review. |
2021-04-27
|
16 | Linda Dunbar | Tag Other - see Comment Log set. Tag Doc Shepherd Follow-up Underway cleared. |
2021-04-27
|
16 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability]. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read this document and have provided feedback on previous revisions to the authors. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2021-04-27
|
16 | Linda Dunbar | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-04-27
|
16 | Linda Dunbar | IESG state changed to Publication Requested from I-D Exists |
2021-04-27
|
16 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2021-04-27
|
16 | Linda Dunbar | IESG process started in state Publication Requested |
2021-04-22
|
16 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2021-03-27
|
16 | Linda Dunbar | Tag Doc Shepherd Follow-up Underway set. |
2021-03-27
|
16 | Linda Dunbar | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2021-03-08
|
16 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-16.txt |
2021-03-08
|
16 | (System) | New version approved |
2021-03-08
|
16 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-03-08
|
16 | Jaehoon Paul Jeong | Uploaded new revision |
2021-03-08
|
16 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-03-08
|
16 | Jaehoon Paul Jeong | Uploaded new revision |
2021-01-17
|
15 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-15.txt |
2021-01-17
|
15 | (System) | New version approved |
2021-01-17
|
15 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2021-01-17
|
15 | Jaehoon Paul Jeong | Uploaded new revision |
2020-12-30
|
14 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-14.txt |
2020-12-30
|
14 | (System) | New version approved |
2020-12-30
|
14 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , Qiushi Lin , Robert Moskowitz , Susan Hares |
2020-12-30
|
14 | Jaehoon Paul Jeong | Uploaded new revision |
2020-11-06
|
13 | Michael Scharf | Request for Early review by TSVART Completed: Almost Ready. Reviewer: Michael Scharf. Sent review to list. |
2020-11-02
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-11-02
|
13 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-13.txt |
2020-11-02
|
13 | (System) | New version approved |
2020-11-02
|
13 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jinyong Kim , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2020-11-02
|
13 | Jaehoon Paul Jeong | Uploaded new revision |
2020-10-20
|
12 | Magnus Westerlund | Request for Early review by TSVART is assigned to Michael Scharf |
2020-10-20
|
12 | Magnus Westerlund | Request for Early review by TSVART is assigned to Michael Scharf |
2020-10-20
|
12 | Magnus Westerlund | Requested Early review by TSVART |
2020-10-12
|
12 | Wesley Eddy | Closed request for Telechat review by TSVART with state 'Overtaken by Events' |
2020-10-05
|
12 | David Black | Assignment of request for Telechat review by TSVART to David Black was rejected |
2020-10-05
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to David Black |
2020-10-05
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to David Black |
2020-10-03
|
12 | Joseph Touch | Assignment of request for Telechat review by TSVART to Joseph Touch was rejected |
2020-09-29
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Joseph Touch |
2020-09-29
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Joseph Touch |
2020-09-29
|
12 | Kyle Rose | Assignment of request for Telechat review by TSVART to Kyle Rose was rejected |
2020-09-28
|
12 | Roman Danyliw | Removed from agenda for telechat |
2020-09-28
|
12 | Roman Danyliw | Tag Doc Shepherd Follow-up Underway cleared. |
2020-09-28
|
12 | Roman Danyliw | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2020-09-28
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Kyle Rose |
2020-09-28
|
12 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Kyle Rose |
2020-09-28
|
12 | Roman Danyliw | Based on preliminary feedback from the IESG in preparation for the September 24, 2020 telechat, this document was initially deferred (from this telechat). After further … Based on preliminary feedback from the IESG in preparation for the September 24, 2020 telechat, this document was initially deferred (from this telechat). After further discussion between the AD+I2NSF chairs, this document is being sent back to the WG to determine how to best resolve the dependency on the capabilities information model (i.e., draft-ietf-i2nsf-capability). |
2020-09-28
|
12 | Roman Danyliw | IESG state changed to I-D Exists from IESG Evaluation - Defer |
2020-09-28
|
12 | Magnus Westerlund | Requested Telechat review by TSVART |
2020-09-24
|
12 | Cindy Morgan | Telechat date has been changed to 2020-10-08 from 2020-09-24 |
2020-09-24
|
12 | Magnus Westerlund | [Ballot discuss] I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack … [Ballot discuss] I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack the semantics to understand if they do map to protocol values. This discuss is more a place holder to be aware that this document needs to re-reviewed after having addressed by transport people. |
2020-09-24
|
12 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2020-09-24
|
12 | Roman Danyliw | This document now replaces draft-hares-i2nsf-capability-data-model instead of None |
2020-09-24
|
12 | Alvaro Retana | [Ballot comment] The datatracker should indicate that this draft replaces draft-hares-i2nsf-capability-data-model. I support the DISCUSS positions from Erik and Ben. |
2020-09-24
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-09-24
|
12 | Murray Kucherawy | [Ballot comment] I support Eric's DISCUSS position about the information model vs. data model publications. The smashed-together list of references at the top of Section … [Ballot comment] I support Eric's DISCUSS position about the information model vs. data model publications. The smashed-together list of references at the top of Section 5 could use some formatting. I tripped over several of the editorial points Barry found. Here's one more. In Section 3: o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Block malicious users "for" IPv6 traffic? I don't understand. Perhaps "block IPv6 traffic from malicious users"? |
2020-09-24
|
12 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-09-23
|
12 | Roman Danyliw | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2020-09-22
|
12 | Benjamin Kaduk | [Ballot discuss] There are many elements of the YANG module whose semantics seem underspecified to me. I noted quite a few in the COMMENT section, … [Ballot discuss] There are many elements of the YANG module whose semantics seem underspecified to me. I noted quite a few in the COMMENT section, and I hope that those aspects of my comments are clear (as it would be substantial effort to partition the comments and move the questions of unclear semantics into the discuss section), but I am happy to assist in the classification if needed. I think that the data nodes of this module as written are probably not reflecting the intent -- it seems that the only elements of the 'nsf' list are the string nsf-name; there is no "uses nsf-capabilities" stanza to bring in the grouping that contains all the interesting parts. Specifically, I do not see how the tree diagram reflects the current module. I'm surprised to not see any discussion of privacy considerations -- some of the features that we define capability indicators for are highly sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify individuals, web filtering) that inherently require access to individuals' private data. Not only should we note that private information is made accessible in this manner, but we should also reiterate that the nodes/entities given access to this data need to be tightly secured and monitored, to prevent leakage or other unauthorized disclosure of private data. I also think we need to mention that authentication and proper authorization will be needed to register as an NSF providing these capabilities. The examples do not seem to conform to the current module structure (e.g., exact-fourth-layer-port-num and range-fourth-layer-port-num). I worry a little bit that even the structure of the tree risks "imposing functional requirements or constraints" upon NSF developers (in the words of the framework). How would, for example, SCTP capabilities be indicated, let alone QUIC? (With an augmentation, clearly, but is that undue burden?) While the classification into ingress/egress/log is natural, it also may be found limiting; consider, for example, a setup involving port mirroring -- is that an ingress action or egress? If traffic is dropped as part of a different ingress filtering capability, does it still get sent to the port mirror? |
2020-09-22
|
12 | Benjamin Kaduk | [Ballot comment] It's a little weird to have the data model be up for review when the information model is still in AD Evaluation, but … [Ballot comment] It's a little weird to have the data model be up for review when the information model is still in AD Evaluation, but probably not catastrophic. Section 1 As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and smartphone using Voice over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a nit: missing verb for "network devices". registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be nit: I'd probably say that it's the knowledge of those capabilities or a database of those capabilities that is maintained centrally. o Definition for condition capabilities of generic network security functions. o Definition for condition capabilities of advanced network security functions. [I'm not yet sure at this point that I understand the need for distinguishing between generic and advanced network security functions ... won't the boundary between those categories evolve over time?] Section 3 Framework. As shown in this figure, an NSF Developer's Management System can register NSFs and the capabilities that the network security device can support. To register NSFs in this way, the nit: s/device/devices/ That is, this Registration Interface uses the YANG module described in this document to describe the capability of a network security function that is registered with the Security Controller. With the nit: "capabilities" plural probably makes more sense in this context. capabilities of those network security devices maintained centrally, [similar comment about "maintained centrally" as above] Note that the NSF-Facing Interface [RFC8329] is used to configure the security policy rules of the generic network security functions, and The configuration of advanced security functions over the NSF-Facing nit: lowercase 'l' in "the". o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). I'm not entirely sure why only the IPv6 traffic of a malicious user would be blocked. Also, nit/edtiorial-level, "using the I2NSF Consumer-Facing Interface" would read more naturally to me than "using the I2NSF User". Section 4.1 The NSF capabilities in the tree include time capabilities, event capabilities, condition capabilities, action capabilities, resolution strategy capabilities, and default action capabilities. Those In Section 1 we had a similar list that used "general capabilities" compared to "time capabilities" here. Is this distinction intentional? (Given that the tree diagram and actual module use the "time" variant, it's not entirely clear what the "general" variant would be...) repeated time like day, week, or month. See Section 3.4.6 (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more information about the time-based condition (e.g., time period) in the capability algebra. Following the reference, it seems to just use time-based condition as an example of an arbitrary condition -- I don't see any specific discussion that mentions considerations specific to time-based conditions. event and system alarm. See Section 3.1 (Design Principles and ECA Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more information about the event in the ECA policy model. (side note) I followed the reference and was surprised that I couldn't find any specific indication that an Event of '{}' evaluates to true (at least, I assume it does). advanced network security functions. The condition capabilities of generic network security functions are defined as IPv4 capability, IPv6 capability, TCP capability, UDP capability, and ICMP capability. The condition capabilities of advanced network security functions are defined as anti-virus capability, anti-DDoS capability, Intrusion Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE capability. See Section 3.1 (Design Principles and ECA Policy Model At this point in the document I don't understand why VoIP and VoLTE are fit to group together into a single capability. Is the condition clause just looking at a phone number and not other aspects of the call? the ingress and egress actions. In addition, see Section 9.1 (Flow- Based NSF Capability Characterization) for more information about logging at NSFs. [this is section 9.1 of [I-D.ietf-i2nsf-capability] still, though the additional discussion on logging is fairly minimal.] Section 5 In general there seems to be a lot of content in "reference" stanzas that to my non-expert eye would have been more appropriate in the "description" stanza. identity event { description "Base identity for I2NSF policy events."; I note that draft-ietf-i2nsf-capability uses the phrase "I2NSF Event", "I2NSF Policy", and "I2NSF Policy Rule" but not "I2NSF policy event", which makes me suspect that this is an editorial error. (draft-ietf-i2nsf-nsf-monitoring-data-model doesn't use "I2NSF policy event", either.) identity hardware-alarm { base system-alarm-capability; description "Identity for hardware alarm"; How do I decide when to use hardware-alarm vs, e.g., memory-alarm or cpu-alarm? identity condition { description "Base identity for policy conditions"; } Similarly to for events, draft-ietf-i2nsf-capability seems to only use "I2NSF Condition", not "I2NSF policy condition". In this case, the use of "policy" does not feel as out of place to me as it did for events, though. identity context-capability { [...] reference "draft-ietf-i2nsf-capability-05: Information Model of NSFs Capabilities - The operating context of an NSF."; } I don't see the "the operating context of an NSF" in the referenced draft, and in fact "context" is not used as a technical term at all. (Similarly for "identity access-control-list"'s "The context of an NSF".) identity application-layer-filter { base context-capability; description "Identity for application-layer-filter condition capability"; This seems likely to be highly dependent on what exactly the application layer is! I'm not sure that such a generic capability will be useful in practice. identity user { [...] reference "draft-ietf-i2nsf-capability-05: Information Model of NSFs Capabilities - A user in an application of a policy rule to be applied by an NSF. RFC 8519: YANG Data Model for Network Access Control Lists (ACLs) - An access control for a user (e.g., the corresponding IP address) in an NSF."; I'm fairly concerned about implying that it's safe and effective to use an IP address to identify a user. While this works often enough that we have stringent privacy considerations regarding storage/conveyance of IP addresses in logs, in the context of automated network (security) functions the risk of collatoral damage seems quite large. identity group { [...] reference "draft-ietf-i2nsf-capability-05: Information Model of NSFs Capabilities - A group (i.e., a set of users) in an application of a policy rule to be applied by an NSF. RFC 8519: YANG Data Model for Network Access Control Lists (ACLs) - An access control for a group (e.g., the corresponding IP address) in an NSF."; An IP address can identify a group, too? identity geography { base context-capability; description "Identity for geography condition capability"; reference "draft-ietf-i2nsf-capability-05: Information Model of NSFs Capabilities - A group (i.e., a set of users) in an application of a policy rule to be applied by an NSF. I'm not sure what's going on here -- why are groups relevant for geography? RFC 8519: YANG Data Model for Network Access Control Lists (ACLs) - An access control for a geographical location i.e., geolocation (e.g., the corresponding IP address) in an NSF. RFC 8519 doesn't itself talk about geographic location. RFC 8805: A Format for Self-Published IP Geolocation Feeds - An IP address with geolocation information."; I question the utility of self-published geolocation information for the application of (security) policy -- my understanding is that this reference was intended to avoid (among other things) the issue where the IETF meeting network gets geolocated to the location of the previous IETF meeting for the first couple days of the week, which is a convenience/performance application, not a security one. identity ipv4-capability { base condition; description "Identity for IPv4 condition capability"; This identity is used as a base identity for other capabilities; is it intended to also be used as a standalone capability? If not, I suggest including "base" in the description. If so, please clarify what the semantics are. identity ipv4-id { base ipv4-capability; description "Identity for identification condition capability"; (side note) I'd suggest making some mention of "fragment" or "fragmentation" here, in light of RFC 6864. identity ipv6-capability { base condition; description "Identity for IPv6 condition capabilities"; [same as for ipv4-capability] identity exact-ipv6-flow-label { [...] reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Flow Label"; RFC 6437 seems relevant as well. (Similarly for range-ipv6-flow-label.) identity tcp-capability { base condition; description "Identity for TCP condition capabilities"; [same as for ipv4-capability] identity exact-tcp-seq-num { base tcp-capability; description "Identity for exact-match TCP sequence number condition capability"; It's not entirely clear to me why there is need to match on the TCP sequence number, which per RFC 6528 should be effectively random from the vantage of a stateless NSF device. identity exact-tcp-ack-num { base tcp-capability; description "Identity for exact-match TCP acknowledgement number condition capability"; Likewise, the ack number should be effectively random to a stateless NSF. identity udp-capability { base condition; description "Identity for UDP condition capabilities"; [same as for ipv4-capability] identity icmp-capability { base condition; description "Identity for ICMP condition capability"; [ditto] identity icmpv6-capability { base condition; description "Identity for ICMPv6 condition capability"; [ditto] identity url-capability { base condition; description "Identity for URL condition capability"; [ditto] identity pre-defined { base url-capability; description "Identity for URL pre-defined condition capability"; } identity user-defined { base url-capability; description "Identity for URL user-defined condition capability"; } With such sparse description and no reference, I have no idea what functionality this is supposed to indicate. identity log-action-capability { description "Identity for log-action capability"; [same as for ipv4-capability] identity rule-log { base log-action-capability; description "Identity for rule log log-action capability"; } identity session-log { base log-action-capability; description "Identity for session log log-action capability"; } [same as for pre-defined/user-defined] identity egress-action-capability { description "Base identity for egress-action capability"; Why does egress-action-capability get described as a "base identity" but ingress-action-capability and default-action-capability do not? identity tunnel-encapsulation { base egress-action-capability; description "Identity for tunnel encapsulation action capability"; Given that there is more than one tunneling technology available (within the IETF, even!), it's not really clear that this capability will be useful. If a node that only does IPsec wants to talk to a node that only does VXLAN, there's not going to be much tunneling going on. identity voip-volte-capability { [...] reference "RFC 3261: SIP: Session Initiation Protocol RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF VoIP/VoLTE security service capability"; RFC 8329 doesn't talk about "voice" or "VoLTE" at all. identity exception-application { [...] reference "RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF Anti-Virus Exception Application capability"; RFC 8329 doesn't talk about "Anti-Virus Exception" at all (and it's not a term I've encountered previously, so with no other reference I have no idea what it's supposed to mean). (Similarly for exception-signature.) identity voice-id { base voip-volte-capability; description "Identity for advanced NSF VoIP/VoLTE Voice-ID capability. This can be used for an extension point for VoIP/VoLTE Voice-ID as an advanced NSF."; It sounds like this "voice-ID" is doing voiceprint analysis to identify humans, which would have rather significant implications for the privacy considerations of the system. reference "RFC 3261: SIP: Session Initiation Protocol RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF VoIP/VoLTE Security Service capability"; [still no voice/VoLTE in 8329; I'm probably not going to catch all of these] container generic-nsf-capabilities { description "Conditions capabilities. If a network security function has the condition capabilities, the network security function supports rule execution according to conditions of IPv4, IPv6, TCP, UDP, ICMP, ICMPv6, and payload."; nit: the "and" implies that an NSF has to support all of those if any condition capability is present, which I don't think is the intent. description "Default action capabilities. A default action is used to execute I2NSF policy rules when no rule matches a packet. The default action is defined as pass, drop, alert, or mirror."; Does "alert" setill let the packet pass, or drop it? Section 7 "ietf-i2nsf-capability" is not a data node; it's the module name. (That said, I don't really disagree with the assessment that all the nodes in the module are sensitive, for the listed reasons.) Also, I believe it's conventionally assumed that nodes sensitive for write are also sensitive for read, and don't need to be listed again. Section 8.1 RFCs 3444 and 8431 do not seem to be referenced anywhere in the document. RFCs 3849 and 5737 may not need to be normative (we use the reserved addresses for documentation but the reader doesn't need to rely on that per se). Appendix A.3 The figure lists only "user-defined" as an advanced capability but the prose claims http and https inspection. Appendix A.5 We don't seem to use the address of the NSF anywhere, so there doesn't seem to be need to state what its address is assumed to be. (This would also render the RFC 5737 and RFC 3849 references unused.) |
2020-09-22
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-09-22
|
12 | Erik Kline | [Ballot discuss] [ general ] * At a high level, I'm slightly concerned about the state of the IP-geo aspects of this document. It's … [Ballot discuss] [ general ] * At a high level, I'm slightly concerned about the state of the IP-geo aspects of this document. It's not obvious to me what's desired (nor what may be achievable) here. [1] RFC 8805 In section 5, there's a reference to 8805. This document is an Independent Stream Editor's document, and not an IETF standard. I don't know if that's technically disqualifying from being listed as a Normative reference or not. Regardless, it certainly does not represent any formal industry consensus. [2] ipv4-geo-ip This references draft-ietf-i2nsf-capability, but I cannot find any discussion of IPv4 address geolocation in that document (admittedly I have not read it thoroughly). [3] ipv6-geo-ip I did not find an analogous geo-ip element for IPv6. If there should be support for geolocation for one address family there should probably be support for the other. |
2020-09-22
|
12 | Erik Kline | [Ballot comment] [[ comments ]] [ section 1 ] * This document describes a YANG model outlining a few more I2NSF documents than just … [Ballot comment] [[ comments ]] [ section 1 ] * This document describes a YANG model outlining a few more I2NSF documents than just i2nsf-capability, including: - i2nsf-nsf-monitoring-data-model - i2nsf-sdn-ipsec-flow-protection Indeed, this is noted in section 5. I think it could help the reader when they get to section 4.1 if some earlier section also noted the more complete list of references that section 5 does. [ section 4.1 ] * ICMPv6 is notable by its absence from the list in the paragraph describing the "condition capabilities of generic network security functions". [ section 5 ] * The meaning of ipv6-protocol is not immediately obvious, and may be redundant with ipv6-next-header (the actual name of the header field). Or rather, does ipv6-protocol here mean IPv6 itself (as in the value "6" or "true" meaning 'is capable of')? Or does this mean the first non-IPv6-extension-header next-header value? [[ nits ]] [ section 1 ] * "As the industry becomes more sophisticated and network devices (...)," This is not a grammatically complete clause. Maybe just something like: "...and network devices (...) continue to proliferate, ..." or something. [ section 3 ] * "at a Developer's Management Systems" -> "at a Developer's Management System" * "managing the capabilities of NSFs in this document" -> "managing the capabilities of NSFs as described in this document"? * "network administrator ..., he sends" -> "network administrator ..., they send" * "sends that security policy rules" -> "sends that security policy rule" * "This lets an I2NSF User not consider NSFs where the rule is applied." I found this confusing. Does it mean to say something like "...where the rule is not applicable"? |
2020-09-22
|
12 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2020-09-22
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-09-21
|
12 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. While I do appreciate that a data model (this document) is derived from an … [Ballot discuss] Thank you for the work put into this document. While I do appreciate that a data model (this document) is derived from an information model, I am concerned that the information model is an expired draft whereas I would expect the information model being published first. Else, what is the use of the information model ? What was the WG reasoning behind 'putting the cart before the horses' ? My concern is that by publishing the YANG model, there is nearly no way to change the information model anymore. Please find below a couple of non-blocking COMMENT points but also a couple of blocking DISCUSS points around IPv6. They should be easy to resolve. I would hate to have NSF having basic IPv6 capabilities that cannot be configured by using the YANG model of this document. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.1 -- It is quite common to apply conditions based on the whole IPv6 extension header chain (i.e., presence of destination option header or wrong order of the extension headers). Why is there no such capabilities in this YANG module ? The only one is 'identity ipv6-next-header' that applies only to the first extension header. What is the difference between 'identity ipv6-protocol' and 'identity ipv6-next-header' ? There is no 'protocol' field in the IPv6 header. While fragmented IPv4 packets are part of the conditions ('identity ipv4-fragment-flags'), there is no equivalent in IPv6. |
2020-09-21
|
12 | Éric Vyncke | [Ballot comment] -- Section 4.1 -- May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even … [Ballot comment] -- Section 4.1 -- May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even is SCTP is not heavily used). Is there a real reason to have two related containers ? generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single one ? Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, addresses are filtered/matched by using a prefix length and not a range (that is difficult to implement in hardware). Is there a reason why ICMP(v6) codes are not part of the conditions ? |
2020-09-21
|
12 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2020-09-18
|
12 | Barry Leiba | [Ballot comment] While most of these comments are editorial, some of them are dealing with text that's difficult to understand because of the editorial issues. … [Ballot comment] While most of these comments are editorial, some of them are dealing with text that's difficult to understand because of the editorial issues. Please consider these: — Section 1 — As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and smartphone using Voice over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a lot of problems described in [RFC8192]. This sentence seems a bit fractured. What about network devices? It looks like there’s something missing after the parenthetical. Please re-work this sentence. — Section 3 — This section provides as overview of how the YANG data model can be Typo: “provides an overview”. The configuration of advanced security functions over the NSF-Facing Interface is used to configure the security policy rules of advanced network security functions (e.g., anti-virus and Distributed-Denial- of-Service (DDoS) attack mitigator), respectively, according to the capabilities of NSFs registered with the I2NSF Framework. I don’t see what “respectively” refers to, as the sentence only talks about configuring one thing (“the security policy rules of advanced network security functions”). Also, it seems odd to say “the configuration of … is used to configure …”. Probably should fix that. o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Please consider not making the network administrator male (“he”). o When the Network Operator Management System receives the security policy rule, it automatically sends that security policy rules to appropriate NSFs Change “rules” to singular “rule” to match the first half of the sentence. — Section 7 — You twice say “transport secure transport”, which should just be “secure transport”. o ietf-i2nsf-capability: An attacker could alter the security capabilities associated with an NSF whereby disabling or enabling the evasion of security mitigations. I don’t think “whereby” is the right word here, but I can’t figure out what you’re trying to say well enough to suggest what the right word is. Maybe just “by”? And I don’t know what it means to “disable the evasion of” something. So this sentence needs some work, please. These are the subtrees and data nodes and their sensitivity/vulnerability: Something’s missing here. Maybe just “is”? Maybe something else? |
2020-09-18
|
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-09-16
|
12 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-09-16
|
12 | Cindy Morgan | Placed on agenda for telechat - 2020-09-24 |
2020-09-16
|
12 | Roman Danyliw | Ballot has been issued |
2020-09-16
|
12 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2020-09-16
|
12 | Roman Danyliw | Created "Approve" ballot |
2020-09-16
|
12 | Roman Danyliw | Ballot writeup was changed |
2020-09-15
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-09-15
|
12 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-12.txt |
2020-09-15
|
12 | (System) | New version approved |
2020-09-15
|
12 | (System) | Request for posting confirmation emailed to previous authors: Susan Hares , Jinyong Kim , Jaehoon Jeong , Qiushi Lin , Robert Moskowitz |
2020-09-15
|
12 | Jaehoon Paul Jeong | Uploaded new revision |
2020-09-15
|
11 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2020-09-08
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-09-08
|
11 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-11.txt |
2020-09-08
|
11 | (System) | New version approved |
2020-09-08
|
11 | (System) | Request for posting confirmation emailed to previous authors: Robert Moskowitz , Qiushi Lin , Jaehoon Jeong , Jinyong Kim , Susan Hares |
2020-09-08
|
11 | Jaehoon Paul Jeong | Uploaded new revision |
2020-09-08
|
10 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2020-09-08
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-09-08
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-08. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-i2nsf-capability-data-model-08. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: yang:ietf-i2nsf-capability URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a single, new YANG module will be registered as follows: Name: ietf-i2nsf-capability File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Prefix: nfscap Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-09-08
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-09-06
|
10 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-10.txt |
2020-09-06
|
10 | (System) | New version approved |
2020-09-06
|
10 | (System) | Request for posting confirmation emailed to previous authors: Susan Hares , Jinyong Kim , Qiushi Lin , Jaehoon Jeong , Robert Moskowitz |
2020-09-06
|
10 | Jaehoon Paul Jeong | Uploaded new revision |
2020-09-03
|
09 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list. |
2020-09-03
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2020-09-03
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2020-08-28
|
09 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-09.txt |
2020-08-28
|
09 | (System) | New version approved |
2020-08-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jaehoon Jeong , Susan Hares , Robert Moskowitz , Jinyong Kim |
2020-08-28
|
09 | Jaehoon Paul Jeong | Uploaded new revision |
2020-08-27
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-08-27
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-08-27
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2020-08-27
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2020-08-25
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-08-25
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-09-08): From: The IESG To: IETF-Announce CC: draft-ietf-i2nsf-capability-data-model@ietf.org, dunbar.ll@gmail.com, rdd@cert.org, i2nsf@ietf.org, i2nsf-chairs@ietf.org … The following Last Call announcement was sent out (ends 2020-09-08): From: The IESG To: IETF-Announce CC: draft-ietf-i2nsf-capability-data-model@ietf.org, dunbar.ll@gmail.com, rdd@cert.org, i2nsf@ietf.org, i2nsf-chairs@ietf.org, Linda Dunbar Reply-To: last-call@ietf.org Sender: Subject: Last Call: (I2NSF Capability YANG Data Model) to Proposed Standard The IESG has received a request from the Interface to Network Security Functions WG (i2nsf) to consider the following document: - 'I2NSF Capability YANG Data Model' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3556/ https://datatracker.ietf.org/ipr/3606/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8329: Framework for Interface to Network Security Functions (Informational - IETF stream) rfc8192: Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases (Informational - IETF stream) rfc790: Assigned numbers (Historic - Legacy stream) rfc3444: On the Difference between Information Models and Data Models (Informational - IETF stream) draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF Monitoring YANG Data Model (None - IETF stream) |
2020-08-25
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-08-25
|
08 | Roman Danyliw | Last call was requested |
2020-08-25
|
08 | Roman Danyliw | Last call announcement was generated |
2020-08-25
|
08 | Roman Danyliw | Ballot approval text was generated |
2020-08-25
|
08 | Roman Danyliw | Ballot writeup was generated |
2020-08-25
|
08 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-08-25
|
08 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-08.txt |
2020-08-25
|
08 | (System) | New version approved |
2020-08-25
|
08 | (System) | Request for posting confirmation emailed to previous authors: Jinyong Kim , Qiushi Lin , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2020-08-25
|
08 | Jaehoon Paul Jeong | Uploaded new revision |
2020-08-25
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-08-25
|
07 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-07.txt |
2020-08-25
|
07 | (System) | New version approved |
2020-08-25
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Qiushi Lin , Jinyong Kim , Susan Hares , Robert Moskowitz |
2020-08-25
|
07 | Jaehoon Paul Jeong | Uploaded new revision |
2020-08-21
|
06 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2020-07-13
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-13
|
06 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-06.txt |
2020-07-13
|
06 | (System) | New version approved |
2020-07-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: Robert Moskowitz , Jinyong Kim , Qiushi Lin , Jaehoon Jeong , Susan Hares |
2020-07-13
|
06 | Jaehoon Paul Jeong | Uploaded new revision |
2020-05-12
|
05 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-05-12
|
05 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/i2nsf/Qkup2tKpVyAcelxy3QooLf7P1KI/ |
2020-05-11
|
05 | Roman Danyliw | IESG state changed to AD Evaluation from Publication Requested |
2019-12-11
|
05 | Cindy Morgan | Changed consensus to Yes from Unknown |
2019-12-11
|
05 | Cindy Morgan | Intended Status changed to Proposed Standard from None |
2019-12-11
|
05 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability]. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read this document and have provided feedback on previous revisions to the authors. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2019-12-11
|
05 | Linda Dunbar | Responsible AD changed to Roman Danyliw |
2019-12-11
|
05 | Linda Dunbar | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-12-11
|
05 | Linda Dunbar | IESG state changed to Publication Requested from I-D Exists |
2019-12-11
|
05 | Linda Dunbar | IESG process started in state Publication Requested |
2019-12-11
|
05 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability]. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read this document and have provided feedback on previous revisions to the authors. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2019-12-11
|
05 | Linda Dunbar | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document defines a YANG model for specifying the capability of Network Security Function (NSF), and thus a standard track document is appropriate. The standards track is noted in the header of the document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [draft-ietf-i2nsf-capability]. Working Group Summary: This document was one of the milestones for the I2NSF WG. The document went through long period discussions within the I2NSF WG and with NETMOD WG participants. Many changes were made to utilize the modules that are already specified by draft-ietf-netmod-acl-model as much as possible. The document then went through the YANG Doctor review process. Got good comments and feedback from YANG Doctor Review. The authors addressed feedbacks promptly until the YANG Doctor are satisfied with the YANG models and entered READY for the document. Document Quality: This document is well-written and has gone through a number of working group and external reviews. The YANG module itself validates without any warnings, and have passed YANG Doctor Review. There have been Hackathon implementation and Open source implementation for the YANG model specified by this document. In addition, multiple vendors on the co-author list all indicated that they plan to implement. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd is Linda Dunbar The Responsible Area Director is Roman Danyliw (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read this document and have provided feedback on previous revisions to the authors. I feel this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, I do not. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don’t think so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors replied. These responses can be found in the archives of the I2nsf list. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 2 IPR disclosures were filed against this document. There were some concerns of the IPR terms. After some discussion, the authors had their respective companies change the IPR terms to satisfy WG participants’ requests. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus was strong with no vocalized dissension. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Not to my knowledge. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits found during Shepherd review. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. The document has gone through YANG Doctor review. Has revised to address comments received from YANG Doctor review. YANG Doctor thinks this document ready for publication. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, it will not. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document does not define any new IANA registries, but it does request the following URI in the "IETF XML Registry" [RFC3688]: Uri: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]: name: ietf-i2nsf-capability All the referenced IANA registries have been clearly identified by the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. This document has passed the automated YANG check, which includes a number of validators. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? The YANG module specified by the document has passed the validation and pass the YANG Doctor review. |
2019-12-03
|
05 | Linda Dunbar | Notification list changed to Linda Dunbar <dunbar.ll@gmail.com> |
2019-12-03
|
05 | Linda Dunbar | Document shepherd changed to Linda Dunbar |
2019-12-03
|
05 | Linda Dunbar | Tag Doc Shepherd Follow-up Underway set. |
2019-12-03
|
05 | Linda Dunbar | IETF WG state changed to WG Consensus: Waiting for Write-Up from Adopted by a WG |
2019-11-27
|
05 | Carl Moberg | Request for Last Call review by YANGDOCTORS Completed: Ready. Reviewer: Carl Moberg. Review has been revised by Carl Moberg. |
2019-07-25
|
05 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-05.txt |
2019-07-25
|
05 | (System) | New version approved |
2019-07-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jinyong Kim , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2019-07-25
|
05 | Jaehoon Paul Jeong | Uploaded new revision |
2019-07-15
|
04 | Carl Moberg | Request for Last Call review by YANGDOCTORS Completed: Almost Ready. Reviewer: Carl Moberg. Sent review to list. |
2019-06-26
|
Jenny Bui | Posted related IPR disclosure: Research & Business Foundation Sungkyunkwan University's Statement about IPR related to draft-ietf-i2nsf-capability-data-model and N/A | |
2019-06-08
|
04 | Mehmet Ersue | Closed request for Last Call review by YANGDOCTORS with state 'Withdrawn' |
2019-06-07
|
04 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2019-06-07
|
04 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2019-06-06
|
04 | Linda Dunbar | Requested Last Call review by YANGDOCTORS |
2019-06-06
|
04 | Linda Dunbar | Requested Last Call review by YANGDOCTORS |
2019-06-05
|
Jenny Bui | Posted related IPR disclosure: Research & Business Foundation Sungkyunkwan University's Statement about IPR related to draft-ietf-i2nsf-capability-data-model and N/A | |
2019-05-31
|
04 | Linda Dunbar | Tag Doc Shepherd Follow-up Underway cleared. |
2019-05-31
|
04 | Linda Dunbar | IETF WG state changed to Adopted by a WG from WG Consensus: Waiting for Write-Up |
2019-05-31
|
04 | Linda Dunbar | Tag Doc Shepherd Follow-up Underway set. |
2019-05-31
|
04 | Linda Dunbar | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-03-28
|
04 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-04.txt |
2019-03-28
|
04 | (System) | New version approved |
2019-03-28
|
04 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jinyong Kim , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2019-03-28
|
04 | Jaehoon Paul Jeong | Uploaded new revision |
2019-03-11
|
03 | Jinyong Kim | New version available: draft-ietf-i2nsf-capability-data-model-03.txt |
2019-03-11
|
03 | (System) | New version approved |
2019-03-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jinyong Kim , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2019-03-11
|
03 | Jinyong Kim | Uploaded new revision |
2018-11-04
|
02 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-02.txt |
2018-11-04
|
02 | (System) | New version approved |
2018-11-04
|
02 | (System) | Request for posting confirmation emailed to previous authors: Qiushi Lin , Jinyong Kim , Jaehoon Jeong , Robert Moskowitz , Susan Hares |
2018-11-04
|
02 | Jaehoon Paul Jeong | Uploaded new revision |
2018-07-02
|
01 | Jinyong Kim | New version available: draft-ietf-i2nsf-capability-data-model-01.txt |
2018-07-02
|
01 | (System) | New version approved |
2018-07-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jaehoon Jeong , Jinyong Kim , " linqiushi@huawei.com" , Robert Moskowitz , Susan Hares |
2018-07-02
|
01 | Jinyong Kim | Uploaded new revision |
2018-04-24
|
00 | Jaehoon Paul Jeong | New version available: draft-ietf-i2nsf-capability-data-model-00.txt |
2018-04-24
|
00 | (System) | WG -00 approved |
2018-04-23
|
00 | Jaehoon Paul Jeong | Set submitter to "Jaehoon Paul Jeong ", replaces to (none) and sent approval email to group chairs: i2nsf-chairs@ietf.org |
2018-04-23
|
00 | Jaehoon Paul Jeong | Uploaded new revision |