Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 30 December 2020 16:10 UTC

Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CAD3A08D4; Wed, 30 Dec 2020 08:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.175
X-Spam-Level:
X-Spam-Status: No, score=0.175 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.263, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20MeLPx9m6bK; Wed, 30 Dec 2020 08:10:19 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AA83A08AF; Wed, 30 Dec 2020 08:10:17 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id 23so38562208lfg.10; Wed, 30 Dec 2020 08:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azo0AxjD967Q15lkqh3P4ronsXTj+nDfAoUMQBvCcPo=; b=P4VpnntRCRB1oFCnoljHYyy+Ch4Nc0/hvBiAm9y0QV9Rq1UpU9PLESqAJM3tVt9Z1p FX+9i6vWoXyfbTQvseZAgITzHOsuMXgaj9c5I2wwNeSLdC263RoacGoEWF9bToIvhMtq WLWqhx+Rsm/QDLX7xwo0+cyZYP0Z2Pz7JnVfJkC6DVrIjEKhyNKCas0/07TaPsOqJUlD sErduCKBvYZlzokcfFIJ+28YYwHwoeUe0+e8MtYsxXaR6zMZZ8jN9HCl1s4islAdlgLg uqXiEgZCiUvMltaihv2fuCAHKUHnYwdSh0ZwTAFUtlLo6+OUFmE5CtUCC8AdbXvk8iL6 bBpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azo0AxjD967Q15lkqh3P4ronsXTj+nDfAoUMQBvCcPo=; b=GVHlU+HqqNiRmoPF4jLt4DzrhJ/71SBTxk5rPodTUwr7baJu9YAtpOLBHoR/S5xQV7 Jk7w0zwsvntNq5TByfhh4Cj7KDMtC8MnJ5KnrpVFDriXXYnpV1m6Dr377RQx5fAJlDMo fxqhdKujE8mwwZtAy4MvHAn7/cNJftFR7NqCR5oNI6Rxs6XpuEojF1x9pWXpyiBeu87z MlH3mum+3jSfBXMPVNWidDNgNkUZ0wAP0JD1pvQwgvpgiVhXFZEdqnE2naINjG6G7WEw N41+WrdJdNrOztmGF/WQgYRrNgdQcYySOAeg2uzz5vUncevC1HtSFbbcqnwRDRs+3N5b MzGQ==
X-Gm-Message-State: AOAM531l1cUlrLtWeK/Lf1HPq2jXYgnvId6Q67eJcFIZf6MC75pyHgvC zLAumTUXWtl/KnxzBTIVmzBgiHdv076NvLym7jo=
X-Google-Smtp-Source: ABdhPJw0brMuFZqoDRtbUdy9ougySHrBqjjuQBapGGcfkUlUHwxkBKJhDK3700vV7q/IFXrGrskHdGLj3tdiemSlkPM=
X-Received: by 2002:ac2:5c08:: with SMTP id r8mr23143158lfp.12.1609344614148; Wed, 30 Dec 2020 08:10:14 -0800 (PST)
MIME-Version: 1.0
References: <160083793582.31494.12459352773950908237@ietfa.amsl.com>
In-Reply-To: <160083793582.31494.12459352773950908237@ietfa.amsl.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 31 Dec 2020 01:09:37 +0900
Message-ID: <CAPK2Dey8t6oHWRmj5J=LxoLc2K__OvdO22HG350kSUTbBVCMAA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Éric Vyncke <evyncke@cisco.com>, Erik Kline <ek.ietf@gmail.com>, Barry Leiba <barryleiba@computer.org>, Alvaro Retana <aretana.ietf@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Murray Kucherawy <superuser@gmail.com>, Michael Scharf <michael.scharf@hs-esslingen.de>
Cc: The IESG <iesg@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/mixed; boundary="0000000000000c75f905b7b0be13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/hQP4Ms_FpzImoiFtt9F6sM21ebU>
Subject: Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2020 16:10:26 -0000

Hi Benjamin, Éric, Erik, Murray, Barry, Alvaro, Magnus, and Michael,
I have reflected your comments on the I2NSF Capability YANG Data Model
Draft with the following revision:

https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-14

I attach a revision letter to explain how I have addressed your comments on
the revised draft.

If you have further questions and comments, please let me know.

Thanks.

Best Regards,
Paul
  --
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


On Wed, Sep 23, 2020 at 2:12 PM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-i2nsf-capability-data-model-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/
>
>
>
> ----------------------------------------------------------------------
> 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?
>
>
> ----------------------------------------------------------------------
> 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.)
>
>
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>