From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8819.txt | 808 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 808 insertions(+) create mode 100644 doc/rfc/rfc8819.txt (limited to 'doc/rfc/rfc8819.txt') diff --git a/doc/rfc/rfc8819.txt b/doc/rfc/rfc8819.txt new file mode 100644 index 0000000..1ca39eb --- /dev/null +++ b/doc/rfc/rfc8819.txt @@ -0,0 +1,808 @@ + + + + +Internet Engineering Task Force (IETF) C. Hopps +Request for Comments: 8819 L. Berger +Updates: 8407 LabN Consulting, L.L.C. +Category: Standards Track D. Bogdanovic +ISSN: 2070-1721 Volta Networks + January 2021 + + + YANG Module Tags + +Abstract + + This document provides for the association of tags with YANG modules. + The expectation is for such tags to be used to help classify and + organize modules. A method for defining, reading, and writing + modules tags is provided. Tags may be registered and assigned during + module definition, assigned by implementations, or dynamically + defined and set by users. This document also provides guidance to + future model writers; as such, this document updates RFC 8407. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8819. + +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 and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Some Possible Use Cases for YANG Module Tags + 1.2. Conventions Used in This Document + 2. Tag Values + 2.1. IETF Tags + 2.2. Vendor Tags + 2.3. User Tags + 2.4. Reserved Tags + 3. Tag Management + 3.1. Module Definition Tagging + 3.2. Implementation Tagging + 3.3. User Tagging + 4. Tags Module Structure + 4.1. Tags Module Tree + 4.2. YANG Module + 5. Other Classifications + 6. Guidelines to Model Writers + 6.1. Define Standard Tags + 7. IANA Considerations + 7.1. YANG Module Tag Prefixes Registry + 7.2. IETF YANG Module Tags Registry + 7.3. Updates to the IETF XML Registry + 7.4. Updates to the YANG Module Names Registry + 8. Security Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Examples + Appendix B. Non-NMDA State Module + Acknowledgements + Authors' Addresses + +1. Introduction + + The use of tags for classification and organization is fairly + ubiquitous not only within IETF protocols but in the internet itself + (e.g., "#hashtags"). One benefit of using tags for organization over + a rigid structure is that it is more flexible and can more easily + adapt over time as technologies evolve. Tags can be usefully + registered, but they can also serve as a non-registered mechanism + available for users to define themselves. This document provides a + mechanism to define tags and associate them with YANG modules in a + flexible manner. In particular, tags may be registered as well as + assigned during module definition, assigned by implementations, or + dynamically defined and set by users. + + This document defines a YANG module [RFC7950] that provides a list of + module entries to allow for adding or removing tags as well as + viewing the set of tags associated with a module. + + This document defines an extension statement to indicate tags that + SHOULD be added by the module implementation automatically (i.e., + outside of configuration). + + This document also defines an IANA registry for tag prefixes as well + as a set of globally assigned tags. + + Section 6 provides guidelines for authors of YANG data models. + + This document updates [RFC8407]. + + The YANG data model in this document conforms to the Network + Management Datastore Architecture (NMDA) defined in [RFC8342]. + +1.1. Some Possible Use Cases for YANG Module Tags + + During this document's development, there were requests for example + uses of module tags. The following are a few example use cases for + tags. This list is certainly not exhaustive. + + One example use of tags would be to help filter different discrete + categories of YANG modules supported by a device. For example, if + modules are suitably tagged, then an XPath query can be used to list + all of the vendor modules supported by a device. + + Tags can also be used to help coordination when multiple, semi- + independent clients are interacting with the same devices. For + example, one management client could mark that some modules should + not be used because they have not been verified to behave correctly, + so that other management clients avoid querying the data associated + with those modules. + + Tag classification is useful for users searching module repositories + (e.g., YANG catalog). A query restricted to the 'ietf:routing' + module tag could be used to return only the IETF YANG modules + associated with routing. Without tags, a user would need to know the + name of all the IETF routing protocol YANG modules. + + Future management protocol extensions could allow for filtering + queries of configuration or operational state on a server based on + tags (for example, return all operational state related to system + management). + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Tag Values + + All tags SHOULD begin with a prefix indicating who owns their + definition. An IANA registry (Section 7.1) is used to support + registering tag prefixes. Currently, three prefixes are defined. No + further structure is imposed by this document on the value following + the registered prefix, and the value can contain any YANG type + 'string' characters except carriage returns, newlines, and tabs. + + Again, except for the conflict-avoiding prefix, this document is + purposefully not specifying any structure on (i.e., restricting) the + tag values. The intent is to avoid arbitrarily restricting the + values that designers, implementers, and users can use. As a result + of this choice, designers, implementers, and users are free to add or + not add any structure they may require to their own tag values. + +2.1. IETF Tags + + An IETF tag is a tag that has the prefix "ietf:". All IETF tags are + registered with IANA in a registry defined later in this document + (Section 7.2). + +2.2. Vendor Tags + + A vendor tag is a tag that has the prefix "vendor:". These tags are + defined by the vendor that implements the module and are not + registered; however, it is RECOMMENDED that the vendor include extra + identification in the tag to avoid collisions, such as using the + enterprise or organization name following the "vendor:" prefix (e.g., + vendor:example.com:vendor-defined-classifier). + +2.3. User Tags + + A user tag is any tag that has the prefix "user:". These tags are + defined by the user/administrator and are not meant to be registered. + Users are not required to use the "user:" prefix; however, doing so + is RECOMMENDED as it helps avoid collisions. + +2.4. Reserved Tags + + Any tag not starting with the prefix "ietf:", "vendor:", or "user:" + is reserved for future use. These tag values are not invalid but + simply reserved in the context of specifications (e.g., RFCs). + +3. Tag Management + + Tags can become associated with a module in a number of ways. Tags + may be defined and associated at module design time, at + implementation time, or via user administrative control. As the main + consumer of tags are users, users may also remove any tag, no matter + how the tag became associated with a module. + +3.1. Module Definition Tagging + + A module definition MAY indicate a set of tags to be added by the + module implementer. These design-time tags are indicated using the + module-tag extension statement. + + If the module is defined in an IETF Standards Track document, the + tags MUST be IETF tags (Section 2.1). Thus, new modules can drive + the addition of new IETF tags to the IANA registry defined in + Section 7.2, and the IANA registry can serve as a check against + duplication. + +3.2. Implementation Tagging + + An implementation MAY include additional tags associated with a + module. These tags SHOULD be IETF tags (i.e., registered) or vendor- + specific tags. + +3.3. User Tagging + + Tags of any kind, with or without a prefix, can be assigned and + removed by the user using normal configuration mechanisms. In order + to remove a tag from the operational datastore, the user adds a + matching "masked-tag" entry for a given module. + +4. Tags Module Structure + +4.1. Tags Module Tree + + The tree associated with the "ietf-module-tags" module follows. The + meaning of the symbols can be found in [RFC8340]. + + module: ietf-module-tags + +--rw module-tags + +--rw module* [name] + +--rw name yang:yang-identifier + +--rw tag* tag + +--rw masked-tag* tag + + Figure 1: YANG Module Tags Tree Diagram + +4.2. YANG Module + + file "ietf-module-tags@2021-01-04.yang" + module ietf-module-tags { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; + prefix tags; + + import ietf-yang-types { + prefix yang; + } + + organization + "IETF NetMod Working Group (NetMod)"; + contact + "WG Web: + WG List: + + Author: Christian Hopps + + + Author: Lou Berger + + + Author: Dean Bogdanovic + "; + + description + "This module describes a mechanism associating tags with YANG + modules. Tags may be IANA assigned or privately defined. + + 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 + the license terms contained in, the Simplified BSD License set + forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8819 + (https://www.rfc-editor.org/info/rfc8819); see the RFC itself + for full legal notices. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here."; + + revision 2021-01-04 { + description + "Initial revision."; + reference + "RFC 8819: YANG Module Tags"; + } + + typedef tag { + type string { + length "1..max"; + pattern '[\S ]+'; + } + description + "A tag is a type of 'string' value that does not include + carriage return, newline, or tab characters. It SHOULD begin + with a registered prefix; however, tags without a registered + prefix SHOULD NOT be treated as invalid."; + } + + extension module-tag { + argument tag; + description + "The argument 'tag' is of type 'tag'. This extension statement + is used by module authors to indicate the tags that SHOULD be + added automatically by the system. As such, the origin of the + value for the predefined tags should be set to 'system' + [RFC8342]."; + } + + container module-tags { + description + "Contains the list of modules and their associated tags."; + list module { + key "name"; + description + "A list of modules and their associated tags."; + leaf name { + type yang:yang-identifier; + mandatory true; + description + "The YANG module name."; + } + leaf-list tag { + type tag; + description + "Tags associated with the module. See the IANA 'YANG + Module Tag Prefixes' registry for reserved prefixes and + the IANA 'IETF YANG Module Tags' registry for IETF tags. + + The 'operational' state [RFC8342] view of this list is + constructed using the following steps: + + 1) System tags (i.e., tags of 'system' origin) are added. + 2) User-configured tags (i.e., tags of 'intended' origin) + are added. + 3) Any tag that is equal to a masked-tag is removed."; + } + leaf-list masked-tag { + type tag; + description + "The list of tags that should not be associated with this + module. The user can remove (mask) tags from the + operational state datastore [RFC8342] by adding them to + this list. It is not an error to add tags to this list + that are not associated with the module, but they have no + operational effect."; + } + } + } + } + + + Figure 2: Module Tags Module + +5. Other Classifications + + It is worth noting that a different YANG module classification + document exists [RFC8199]. That document only classifies modules in + a logical manner and does not define tagging or any other mechanisms. + It divides YANG modules into two categories (service or element) and + then into one of three origins: standard, vendor, or user. It does + provide a good way to discuss and identify modules in general. This + document defines IETF tags to support the classification style + described in [RFC8199]. + +6. Guidelines to Model Writers + + This section updates [RFC8407]. + +6.1. Define Standard Tags + + A module MAY indicate, using module-tag extension statements, a set + of tags that are to be automatically associated with it (i.e., not + added through configuration). + + module example-module { + namespace "https://example.com/yang/example"; + prefix "ex"; + //... + import module-tags { prefix tags; } + + tags:module-tag "ietf:some-new-tag"; + tags:module-tag "ietf:some-other-tag"; + // ... + } + + The module writer can use existing standard tags or use new tags + defined in the model definition, as appropriate. For IETF + standardized modules, new tags MUST be assigned in the IANA registry + defined below, see Section 7.2. + +7. IANA Considerations + +7.1. YANG Module Tag Prefixes Registry + + IANA has created the "YANG Module Tag Prefixes" subregistry in the + "YANG Module Tags" registry. + + This registry allocates tag prefixes. All YANG module tags SHOULD + begin with one of the prefixes in this registry. + + Prefix entries in this registry should be short strings consisting of + lowercase ASCII alpha-numeric characters and a final ":" character. + + The allocation policy for this registry is Specification Required + [RFC8126]. The Reference and Assignee values should be sufficient to + identify and contact the organization that has been allocated the + prefix. + + The initial values for this registry are as follows. + + +=========+========================+===========+==========+ + | Prefix | Description | Reference | Assignee | + +=========+========================+===========+==========+ + | ietf: | IETF tags allocated in | RFC 8819 | IETF | + | | the IANA "IETF YANG | | | + | | Module Tags" registry. | | | + +---------+------------------------+-----------+----------+ + | vendor: | Non-registered tags | RFC 8819 | IETF | + | | allocated by the | | | + | | module implementer. | | | + +---------+------------------------+-----------+----------+ + | user: | Non-registered tags | RFC 8819 | IETF | + | | allocated by and for | | | + | | the user. | | | + +---------+------------------------+-----------+----------+ + + Table 1 + + Other standards development organizations (SDOs) wishing to allocate + their own set of tags should allocate a prefix from this registry. + +7.2. IETF YANG Module Tags Registry + + IANA has created the "IETF YANG Module Tags" subregistry within the + "YANG Module Tags" registry . This registry appears below the "YANG + Module Tag Prefixes" registry. + + This registry allocates tags that have the registered prefix "ietf:". + New values should be well considered and not achievable through a + combination of already existing IETF tags. IANA assigned tags must + conform to Net-Unicode as defined in [RFC5198], and they shall not + need normalization. + + The allocation policy for this registry is IETF Review [RFC8126]. + + The initial values for this registry are as follows. + + +============================+=======================+===========+ + | Tag | Description | Reference | + +============================+=======================+===========+ + | ietf:network-element-class | Network element as | [RFC8199] | + | | defined in [RFC8199]. | | + +----------------------------+-----------------------+-----------+ + | ietf:network-service-class | Network service as | [RFC8199] | + | | defined in [RFC8199]. | | + +----------------------------+-----------------------+-----------+ + | ietf:sdo-defined-class | Module is defined by | [RFC8199] | + | | a standards | | + | | organization. | | + +----------------------------+-----------------------+-----------+ + | ietf:vendor-defined-class | Module is defined by | [RFC8199] | + | | a vendor. | | + +----------------------------+-----------------------+-----------+ + | ietf:user-defined-class | Module is defined by | [RFC8199] | + | | the user. | | + +----------------------------+-----------------------+-----------+ + | ietf:hardware | Relates to hardware | RFC 8819 | + | | (e.g., inventory). | | + +----------------------------+-----------------------+-----------+ + | ietf:software | Relates to software | RFC 8819 | + | | (e.g., installed OS). | | + +----------------------------+-----------------------+-----------+ + | ietf:protocol | Represents a protocol | RFC 8819 | + | | (often combined with | | + | | another tag to | | + | | refine). | | + +----------------------------+-----------------------+-----------+ + | ietf:qos | Relates to quality of | RFC 8819 | + | | service. | | + +----------------------------+-----------------------+-----------+ + | ietf:network-service-app | Relates to a network | RFC 8819 | + | | service application | | + | | (e.g., an NTP server, | | + | | DNS server, DHCP | | + | | server, etc.). | | + +----------------------------+-----------------------+-----------+ + | ietf:system-management | Relates to system | RFC 8819 | + | | management (e.g., a | | + | | system management | | + | | protocol such as | | + | | syslog, TACAC+, SNMP, | | + | | NETCONF, etc.). | | + +----------------------------+-----------------------+-----------+ + | ietf:oam | Relates to | RFC 8819 | + | | Operations, | | + | | Administration, and | | + | | Maintenance (e.g., | | + | | BFD). | | + +----------------------------+-----------------------+-----------+ + | ietf:routing | Relates to routing. | RFC 8819 | + +----------------------------+-----------------------+-----------+ + | ietf:security | Related to security. | RFC 8819 | + +----------------------------+-----------------------+-----------+ + | ietf:signaling | Relates to control- | RFC 8819 | + | | plane signaling. | | + +----------------------------+-----------------------+-----------+ + | ietf:link-management | Relates to link | RFC 8819 | + | | management. | | + +----------------------------+-----------------------+-----------+ + + Table 2 + +7.3. Updates to the IETF XML Registry + + This document registers a URI in the "IETF XML Registry" [RFC3688]. + Following the format in [RFC3688], the following registrations have + been made: + + URI: urn:ietf:params:xml:ns:yang:ietf-module-tags + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-module-tags-state + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + +7.4. Updates to the YANG Module Names Registry + + This document registers two YANG modules in the "YANG Module Names" + registry [RFC6020]. Following the format in [RFC6020], the following + registrations have been made: + + name: ietf-module-tags + namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags + prefix: tags + reference: RFC 8819 + + name: ietf-module-tags-state + namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags-state + prefix: tags-s + reference: RFC 8819 + +8. Security Considerations + + The YANG module defined in this memo is designed to be accessed via + the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the + secure transport layer and the mandatory-to-implement secure + transport is Secure Shell (SSH) [RFC6242]. + + This document adds the ability to associate tag metadata with YANG + modules. This document does not define any actions based on these + associations, and none are yet defined; therefore, it does not by + itself introduce any new security considerations directly. + + Users of the tag metadata may define various actions to be taken + based on the tag metadata. These actions and their definitions are + outside the scope of this document. Users will need to consider the + security implications of any actions they choose to define, including + the potential for a tag to get 'masked' by another user. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module + Classification", RFC 8199, DOI 10.17487/RFC8199, July + 2017, . + + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, + . + + [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of + Documents Containing YANG Data Models", BCP 216, RFC 8407, + DOI 10.17487/RFC8407, October 2018, + . + +9.2. Informative References + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network + Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, + . + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + . + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + +Appendix A. Examples + + The following is a fictional NETCONF example result from a query of + the module tags list. For the sake of brevity, only a few module + results are shown. + + + + + ietf-bfd + ietf:network-element-class + ietf:oam + ietf:protocol + ietf:sdo-defined-class + + + ietf-isis + ietf:network-element-class + ietf:protocol + ietf:sdo-defined-class + ietf:routing + + + ietf-ssh-server + ietf:network-element-class + ietf:protocol + ietf:sdo-defined-class + ietf:system-management + + + + + Figure 3: Example NETCONF Query Output + +Appendix B. Non-NMDA State Module + + As per [RFC8407], the following is a non-NMDA module to support + viewing the operational state for non-NMDA compliant servers. + + file "ietf-module-tags-state@2021-01-04.yang" + module ietf-module-tags-state { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; + prefix tags-s; + + import ietf-yang-types { + prefix yang; + } + import ietf-module-tags { + prefix tags; + } + + organization + "IETF NetMod Working Group (NetMod)"; + contact + "WG Web: + WG List: + + Author: Christian Hopps + + + Author: Lou Berger + + + Author: Dean Bogdanovic + "; + + description + "This module describes a mechanism associating tags with YANG + modules. Tags may be IANA assigned or privately defined. + + This is a temporary non-NMDA module that is for use by + implementations that don't yet support NMDA. + + 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 + the license terms contained in, the Simplified BSD License set + forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8819 + (https://www.rfc-editor.org/info/rfc8819); see the RFC itself + for full legal notices."; + + revision 2021-01-04 { + description + "Initial revision."; + reference + "RFC 8819: YANG Module Tags"; + } + + container module-tags-state { + config false; + status deprecated; + description + "Contains the list of modules and their associated tags."; + list module { + key "name"; + status deprecated; + description + "A list of modules and their associated tags."; + leaf name { + type yang:yang-identifier; + mandatory true; + status deprecated; + description + "The YANG module name."; + } + leaf-list tag { + type tags:tag; + status deprecated; + description + "Tags associated with the module. See the IANA 'YANG + Module Tag Prefixes' registry for reserved prefixes and + the IANA 'IETF YANG Module Tags' registry for IETF tags. + + The contents of this list is constructed using the + following steps: + + 1) System tags (i.e., tags of added by the system) are + added. + 2) User-configured tags (i.e., tags added by + configuration) are added. + 3) Any tag that is equal to a masked-tag present in the + corresponding ietf-module-tags:module-tags:module-tag leaf + list for this module is removed."; + } + } + } + } + + + Figure 4: Non-NMDA Module Tags State Module + +Acknowledgements + + Special thanks to Robert Wilton for his help improving the + introduction and providing the example use cases, as well as + generating the non-NMDA module. + +Authors' Addresses + + Christian Hopps + LabN Consulting, L.L.C. + + Email: chopps@chopps.org + + + Lou Berger + LabN Consulting, L.L.C. + + Email: lberger@labn.net + + + Dean Bogdanovic + Volta Networks + + Email: ivandean@gmail.com -- cgit v1.2.3