--- 1/draft-ietf-i2nsf-capability-data-model-18.txt 2021-09-28 21:13:10.553927671 -0700 +++ 2/draft-ietf-i2nsf-capability-data-model-19.txt 2021-09-28 21:13:10.669930569 -0700 @@ -1,24 +1,24 @@ I2NSF Working Group S. Hares, Ed. Internet-Draft Huawei Intended status: Standards Track J. Jeong, Ed. -Expires: 19 March 2022 J. Kim +Expires: 1 April 2022 J. Kim Sungkyunkwan University R. Moskowitz HTT Consulting Q. Lin Huawei - 15 September 2021 + 28 September 2021 I2NSF Capability YANG Data Model - draft-ietf-i2nsf-capability-data-model-18 + draft-ietf-i2nsf-capability-data-model-19 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. Status of This Memo @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 19 March 2022. + This Internet-Draft will expire on 1 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -57,27 +57,27 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Information Model of I2NSF NSF Capability . . . . . . . . . . 4 3.1. Design Principles and ECA Policy Model . . . . . . . . . 5 3.2. Conflict, Resolution Strategy and Default Action . . . . 8 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Network Security Function (NSF) Capabilities . . . . . . 12 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 - 10.2. Informative References . . . . . . . . . . . . . . . . . 56 + 10.2. Informative References . . . . . . . . . . . . . . . . . 55 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 57 A.1. Example 1: Registration for the Capabilities of a General - Firewall . . . . . . . . . . . . . . . . . . . . . . . . 58 + Firewall . . . . . . . . . . . . . . . . . . . . . . . . 57 A.2. Example 2: Registration for the Capabilities of a Time-based Firewall . . . . . . . . . . . . . . . . . . . 59 A.3. Example 3: Registration for the Capabilities of a Web Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.4. Example 4: Registration for the Capabilities of a VoIP/ VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 62 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 63 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65 @@ -103,24 +103,24 @@ Security Capabilities describe the functions that Network Security Functions (NSFs) can provide for security policy enforcement. Security Capabilities are independent of the actual security policy that will implement the functionality of the NSF. Every NSF SHOULD be described with the set of capabilities it offers. Security Capabilities enable security functionality to be described in a vendor-neutral manner. Security Capabilities are a market enabler, providing a way to define customized security protection by unambiguously describing the security features offered by a given - NSF. Note that this YANG data model structurizes the NSF Monitoring - Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] - and the NSF-Facing Interface YANG Data Model - [I-D.ietf-i2nsf-nsf-facing-interface-dm]. + NSF. Note that this YANG data model constructs the structure of the + NSF Monitoring Interface YANG data model + [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing + Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. This document provides an information model and the corresponding YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those NSFs. The NSFs 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 database of the capabilities of those NSFs that are maintained centrally, those NSFs can be more easily managed [RFC8329]. @@ -158,42 +158,42 @@ diagrams is defined in [RFC8340]. 3. Information Model of I2NSF NSF Capability This section provides the I2NSF Capability Information Model (CapIM). A CapIM is a formalization of the functionality that an NSF advertises. This enables the precise specification of what an NSF can do in terms of security policy enforcement, so that computer- based tasks can unambiguously refer to, use, configure, and manage NSFs. Capabilities MUST be defined in a vendor- and technology- - independent manner (e.g., regardless of the differences among vendors + independent manner (i.e., regardless of the differences among vendors and individual products). Humans can refer to categories of security controls and understand each other. For instance, network security experts agree on what is meant by the terms "NAT", "filtering", and "VPN concentrator". As a further example, network security experts unequivocally refer to "packet filters" as stateless devices that allow or deny packet forwarding based on various conditions (e.g., source and destination IP addresses, source and destination ports, and IP protocol type fields) [Alshaer]. However, more information is required in case of other devices, like stateful firewalls or application layer filters. These devices filter packets or communications, but there are differences in the packets and communications that they can categorize and the states they maintain. Humans deal with these differences by asking more questions to determine the specific category and functionality of the device. Machines can follow a similar approach, which is commonly - referred to as question-answering [Hirschman] [Galitsky]. In this - context, the CapIM and the derived data model can provide important - and rich information sources. + referred to as question-answering [Hirschman]. In this context, the + CapIM and the derived data model can provide important and rich + information sources. Analogous considerations can be applied for channel protection protocols, where we all understand that they will protect packets by means of symmetric algorithms whose keys could have been negotiated with asymmetric cryptography, but they may work at different layers and support different algorithms and protocols. To ensure protection, these protocols apply integrity, optionally confidentiality, anti-reply protections, and authentication. The CapIM is intended to clarify these ambiguities by providing a @@ -313,25 +313,25 @@ include matching attributes of a packet or flow, and comparing the internal state of an NSF with a desired state. * Action: An action is used to control and monitor aspects of NSFs to handle packets or flows when the event and condition clauses are satisfied. NSFs provide security functions by executing various Actions. Examples of I2NSF actions include providing intrusion detection and/or protection, web and flow filtering, and deep packet inspection for packets and flows. - An I2NSF Policy Rule is made up of three Boolean clauses: an Event - clause, a Condition clause, and an Action clause. This structure is - also called an ECA (Event-Condition-Action) Policy Rule. A Boolean - clause is a logical statement that evaluates to either TRUE or FALSE. - It may be made up of one or more terms; if more than one term is + An I2NSF Policy Rule is made up of three clauses: an Event clause, a + Condition clause, and an Action clause. This structure is also + called an ECA (Event-Condition-Action) Policy Rule. A Boolean clause + is a logical statement that evaluates to either TRUE or FALSE. It + may be made up of one or more terms; if more than one term is present, then each term in the Boolean clause is combined using logical connectives (i.e., AND, OR, and NOT). An I2NSF ECA Policy Rule has the following semantics: IF is TRUE IF is TRUE THEN execute [constrained by metadata] @@ -664,112 +664,115 @@ This section introduces a YANG module for NSFs' capabilities, as defined in the Section 3. It makes references to * [RFC0768] * [RFC0791] * [RFC0792] - * [RFC0793] - * [RFC0854] * [RFC0959] * [RFC1939] * [RFC2474] - * [RFC2616] - * [RFC2818] * [RFC3168] * [RFC3261] * [RFC3501] + * [RFC4250] + * [RFC4340] * [RFC4443] * [RFC4766] * [RFC4960] - * [RFC5101] + * [RFC5103] * [RFC5321] * [RFC5595] * [RFC6335] * [RFC6437] * [RFC6691] * [RFC6864] * [RFC7230] * [RFC7231] - * [RFC7323] + * [RFC7323] * [RFC8200] * [RFC8329] * [RFC8805] * [IEEE802.3-2018] * [IANA-Protocol-Numbers] * [I-D.ietf-tcpm-rfc793bis] * [I-D.ietf-tcpm-accurate-ecn] * [I-D.ietf-tsvwg-udp-options] * [I-D.ietf-i2nsf-nsf-monitoring-data-model] - file "ietf-i2nsf-capability@2021-09-15.yang" + file "ietf-i2nsf-capability@2021-09-28.yang" module ietf-i2nsf-capability { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; prefix nsfcap; organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: - Editor: Jaehoon Paul Jeong + Editor: Susan Hares + + + Editor: Jaehoon (Paul) Jeong - Editor: Jinyong Tim Kim + Editor: Jinyong (Tim) Kim - Editor: Patrick Lingga - + Editor: Robert Moskowitz + - Editor: Susan Hares - "; + Editor: Qiushi Lin + + Editor: Patrick Lingga + "; description "This module is a YANG module for I2NSF Network Security Functions (NSFs)'s Capabilities. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to @@ -778,21 +781,21 @@ Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. - revision "2021-09-15"{ + revision "2021-09-28"{ description "Initial revision."; reference "RFC XXXX: I2NSF Capability YANG Data Model"; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. } /* * Identities @@ -1025,46 +1030,40 @@ reference "RFC 8805: A Format for Self-Published IP Geolocation Feeds - An access control for a geographical location (i.e., geolocation) that has the corresponding IP prefix."; } identity directional { description "Base identity for directional traffic flow capability"; reference - "RFC 5101: Specification of the IP Flow Information - Export (IPFIX) Protocol for the Exchange of IP - Traffic Flow Information - Terminology Unidirectional - and Bidirectional Flow"; + "RFC 5103: Bidirectional Flow Export Using IP Flow Information + Export (IPFIX) - Terminology Unidirectional and Bidirectional + Flow"; } identity unidirectional { base directional; description - "Identity for unirectional traffic flow."; + "Identity for unidirectional traffic flow."; reference - "RFC 5101: Specification of the IP Flow Information - Export (IPFIX) Protocol for the Exchange of IP - Traffic Flow Information - Terminology Unidirectional - Flow"; + "RFC 5103: Bidirectional Flow Export Using IP Flow Information + Export (IPFIX) - Terminology Unidirectional Flow"; } - identity bidirectional { base directional; description "Identity for bidirectional traffic flow."; reference - "RFC 5101: Specification of the IP Flow Information - Export (IPFIX) Protocol for the Exchange of IP - Traffic Flow Information - Terminology Bidirectional - Flow"; + "RFC 5103: Bidirectional Flow Export Using IP Flow Information + Export (IPFIX) - Terminology Bidirectional Flow"; } identity protocol { description "Base identity for protocols"; } identity ethernet { base protocol; description @@ -1384,22 +1384,21 @@ description "Base identity for Layer 4 protocol condition capabilities, e.g., TCP, UDP, SCTP, and DCCP"; } identity tcp { base transport-protocol; description "Base identity for TCP condition capabilities"; reference - "RFC 793: Transmission Control Protocol - draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol + "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity udp { base transport-protocol; description "Base identity for UDP condition capabilities"; reference "RFC 768: User Datagram Protocol"; } @@ -1422,64 +1421,58 @@ identity source-port-number { base tcp; base udp; base sctp; base dccp; description "Identity for matching TCP, UDP, SCTP, and DCCP source port number condition capability"; reference - "RFC 793: Transmission Control Protocol - Port Number - draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol + "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification RFC 768: User Datagram Protocol RFC 4960: Stream Control Transmission Protocol RFC 4340: Datagram Congestion Control Protocol"; - } - identity destination-port-number { base tcp; base udp; base sctp; base dccp; description "Identity for matching TCP, UDP, SCTP, and DCCP destination port number condition capability"; reference - "RFC 793: Transmission Control Protocol - Port Number - draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol + "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity flags { base tcp; description "Identity for TCP control bits (flags) condition capability"; reference - "RFC 793: Transmission Control Protocol - Flags - RFC 3168: The Addition of Explicit Congestion Notification + "RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP - TCP Header Flags draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback in TCP"; } identity tcp-options { base tcp; description "Identity for TCP options condition capability."; reference - "RFC 793: Transmission Control Protocol - Options - draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol + "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification RFC 6691: TCP Options and Maximum Segment Size RFC 7323: TCP Extensions for High Performance"; } identity total-length { base udp; description "Identity for matching UDP total-length condition capability. The UDP total length can be smaller than the IP transport @@ -1525,27 +1516,25 @@ base protocol; description "Base identity for Application protocol"; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol."; reference - "RFC 2616: Hypertext Transfer Protocol (HTTP) - RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message + "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"; } - identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol Secure."; reference "RFC 2818: HTTP over TLS (HTTPS) RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"; @@ -1976,29 +1966,30 @@ 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, SCTP, DCCP, ICMP, or ICMPv6."; reference "RFC 768: User Datagram Protocol - UDP. RFC 791: Internet Protocol - IPv4. RFC 792: Internet Control Message Protocol - ICMP. - RFC 793: Transmission Control Protocol - TCP. RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6. RFC 4960: Stream Control Transmission Protocol - SCTP. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - IPv6. RFC 8329: Framework for Interface to Network Security - Functions - I2NSF Flow Security Policy Structure."; + Functions - I2NSF Flow Security Policy Structure. + draft-ietf-tcpm-rfc793bis-25: Transmission Control + Protocol (TCP) Specification"; leaf-list ethernet-capability { type identityref { base ethernet; } description "Media Access Control (MAC) capabilities"; reference "IEEE 802.3: IEEE Standard for Ethernet"; } @@ -2046,22 +2038,21 @@ - ICMPv6"; } leaf-list tcp-capability { type identityref { base tcp; } description "TCP packet capabilities"; reference - "RFC 793: Transmission Control Protocol - TCP - draft-ietf-tcpm-rfc793bis-25: Transmission Control + "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } leaf-list udp-capability { type identityref { base udp; } description "UDP packet capabilities"; reference @@ -2373,24 +2362,20 @@ . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, DOI 10.17487/RFC0793, September 1981, - . - [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, @@ -2400,49 +2385,44 @@ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, - DOI 10.17487/RFC2616, June 1999, - . - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - DOI 10.17487/RFC2818, May 2000, - . - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . + [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) + Protocol Assigned Numbers", RFC 4250, + DOI 10.17487/RFC4250, January 2006, + . + [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet @@ -2452,24 +2432,24 @@ . [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, March 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . - [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information - Export (IPFIX) Protocol for the Exchange of IP Traffic - Flow Information", RFC 5101, DOI 10.17487/RFC5101, January - 2008, . + [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export + Using IP Flow Information Export (IPFIX)", RFC 5103, + DOI 10.17487/RFC5103, January 2008, + . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for @@ -2509,25 +2489,20 @@ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . - [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. - Kivinen, "Internet Key Exchange Protocol Version 2 - (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October - 2014, . - [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF @@ -2598,20 +2573,24 @@ [I-D.ietf-i2nsf-registration-interface-dm] Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-registration- interface-dm-11, 21 August 2021, . 10.2. Informative References + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . @@ -2644,42 +2623,38 @@ numbers/protocol-numbers.xhtml, September 2020. [IEEE802.3-2018] Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for Ethernet", August 2018, . [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and management of firewall policies", 2004. - [Galitsky] Galitsky, B. and R. Pampapathi, "Can many agents answer - questions better than one", First - Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. - [Hirschman] Hirschman, L. and R. Gaizauskas, "Natural Language Question Answering: The View from Here", Natural Language Engineering 7:4, pgs 275-300, Cambridge University Press , November 2001. [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", ISBN 0-32-120068-3 , 2003. [Martin] Martin, R.C., "Agile Software Development, Principles, Patterns, and Practices", Prentice-Hall , ISBN: 0-13-597444-5 , 2002. - [OODMP] "http://www.oodesign.com/mediator-pattern.html". + [OODMP] "https://www.oodesign.com/mediator-pattern.html". - [OODOP] "http://www.oodesign.com/mediator-pattern.html". + [OODOP] "https://www.oodesign.com/mediator-pattern.html". - [OODSRP] "http://www.oodesign.com/mediator-pattern.html". + [OODSRP] "https://www.oodesign.com/mediator-pattern.html". Appendix A. Configuration Examples This section shows configuration examples of "ietf-i2nsf-capability" module for capabilities registration of general firewall. A.1. Example 1: Registration for the Capabilities of a General Firewall This section shows a configuration example for the capabilities registration of a general firewall in either an IPv4 network or an