Thanks Sue! Adrian
> -----Original Message----- > From: I2nsf [mailto:[email protected]] On Behalf Of Susan Hares > Sent: 10 April 2017 16:08 > To: 'Dale Worley'; [email protected] > Cc: [email protected]; [email protected]; draft-ietf-i2nsf-problem-and-use- > [email protected] > Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 > > Dale: > > Thank you for the review. Please see my comments below. > > Sue > > -----Original Message----- > From: I2nsf [mailto:[email protected]] On Behalf Of Dale Worley > Sent: Tuesday, March 14, 2017 6:17 PM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > Document: draft-ietf-i2nsf-problem-and-use-cases-11 > Reviewer: Dale R. Worley > Review Date: 2017-03-14 > IETF LC End Date: 2017-03-22 > IESG Telechat date: [unknown] > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > All of these nits are editorial. > > >1. Introduction > > > > This document describes the problem statement for Interface to > > Network Security Functions (I2NSF) as well as some I2NSF use cases. > > A summary of the state of the art in the industry and IETF which is > > relevant to I2NSF work is documented in > > [I-D.hares-i2nsf-gap-analysis]. > > >The content of these sentences is very good, but the construction seems to > be peculiar. The document doesn't *describe* the problem statement, the > document *is* a statement. Similarly, hares-i2nsf-gap-analysis *is* a > summary of the state of the art. >So I would use > > > > This document is the problem statement for Interface to Network > > Security Functions (I2NSF) as well as some I2NSF use cases. A > > summary of the state of the art in the industry and IETF which is > > relevant to I2NSF work is [I-D.hares-i2nsf-gap-analysis]. > > Dale > > >But maybe you'll prefer to ask the RFC Editor. > > > > This document also briefly describes the > > following use cases summarized by > > [I-D.pastor-i2nsf-merged-use-cases]: > > > >This sentence should start a new paragraph, as it's not connected to the > sentences before it. > > Thank you for finding these errors. I also needed to change > I-D.hares-i2nsf-gap-analysis to draft-ietf-i2nsf-gap-analysis. > > > >3. Problem Space > > > > The following sub-section describes ... > >s/sub-section describes/sub-sections describe/ > > Thank you - sorry to have missed it. > > >3.1.1. Diverse Types of Security Functions > > > > NSFs by different vendors can have > > different features and have different interfaces. > > > >It might be worth mentioning somewhere what seems to be a convention: > >the document (or at least, section 3.1) is largely oriented toward "service > providers" who sell comprehensive network services (including security > functions) to "customers", but who in turn buy security functions from > "vendors". Perhaps this could be ?>entered as terminology in section 2. > > > >The reason I mention this is that my background is as an end-user (which is > common in the IETF), so the term "service provider" > >Triggers in my mind the idea "someone I buy something from". And the term > "vendor" triggers the *same* idea. But in this draft, the default reader is > a "service provider" and "vendor" is *not* the same thing. > > I've added this text: Security Service Provider: A provider of security > services to the customers (end-users or enterprises) using NSF equipment > purchased from vendors or created by the service provider. > > >This point started to confuse me at the beginning of section 3.1.6. > > > > Security Functions in a Demilitarized Zone (DMZ): Examples of this > > function are firewall/ACLs, IDS/IPS, one or all of AAA services > > NAT, forwarding proxies, and application filtering. > > The phrase "one or all of AAA services NAT" seems to be incorrect. I > suspect there's supposed to be a comma before NAT. > > Good catch. I will fix. > > > Security gateways and VPN concentrators: Examples of these > > functions are; IPsec gateways, Secure VPN concentrators that > > handle bridging secure VPNs, and Secure VPN controllers for data > > flows. > > > Unless "Secure VPN" is a name in itself, "secure" shouldn't be > capitalized. > > Good point. I will fix. > > > 3.1.2. Diverse Interfaces to Control and Monitor NSFs > > > > A challenge for monitoring is that an NSF cannot monitor what it > > cannot view. Therefore, enabling a security function (e.g., firewall > > [I-D.ietf-opsawg-firewalls]) does not mean that a network is > > protected. As such, it is necessary to have a mechanism to monitor > > and provide execution status of NSFs to security and compliance > > management tools. There exist various network security monitoring > > vendor-specific interfaces for forensics and troubleshooting. > > > This paragraph seems awkward. Each sentence is reasonable, but the > connection between them is not clear to me. > > Perhaps the third sentence has the meaning "... it is necesary to have a > mechanism ...to verify that the NSF is seeing the traffic that is intended". > >The last sentence contains "network security monitoring vendor-specific > interfaces" which is awkward. Perhaps > > > > There exist various vendor-specific interfaces for network security > > monitoring, forensics, and troubleshooting. > > New paragraph is below. Is it better > > New/ > A challenge for monitoring prior to mitigation of a security intrusion > is that an NSF cannot monitor what it cannot view. Therefore, enabling a > security function to mitigate an intrusion > (e.g., firewall <xref target="I-D.ietf-opsawg-firewalls"></xref>) > does not mean that a network is protected if there is no monitoring > feedback. > As such, it is necessary to have a mechanism > to monitor and provide execution status of NSFs to security and > compliance management tools. There exist various network security > monitoring vendor-specific interfaces for forensics and > troubleshooting, but an industry standard interface could > provide monitoring across avariety of NSFs. > / > > > > 3.1.4. More Demand to Control NSFs Dynamically > > > The Security Service Providers ... > > >The capitalization of "security service providers" is inconsistent. > > Some times all three words are capitalized, and some times they're not. > Thanks for catching this - I will fix it. > > 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs > > > Service providers may need several operational units to control and > > monitor the NSFs, especially when NSFs become distributed and > > virtualized. > > > > You may want to explain what an "operational unit" is. As far as I can > tell, neither "unit" nor "operational" (in this sense) is used elsewhere in > this draft. > > Thanks for catching this vagueness. > The point the service provides may have to deploy multiple controllers. > > How about: > > Service providers may need to deploy several NSF controllers to control and > monitor the NSFs, especially when NSFs become distributed and > virtualized. > > >3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles > > Many security functions depend on signature files or profiles to > > perform (e.g., IPS/IDS signatures, DDos Open Threat Signaling > > (DOTS) filters). > >I think the words "to perform" should be removed. The sentence makes more > sense to me without those. Or, if there is a meaning that needs to be > specified, "to perform" probably >isn't the right choice. "to work" makes > sense in this place, but is an informal usage. Perhaps "to function". > > [removed "to perform") > > > Today, the construction and use of black list databases > > can be a win-win strategy for all parties involved. > >"win-win strategy" is a hackneyed phrase. This is better > > > Today, the construction and use of black list databases > > can be beneficial for all parties involved. > > >However, it's not clear to me what additional information is carried by > "for all parties involved". And for that matter, is "today" > >important here? > >I suspect that you mean something like this: > > > > Today, black list databases can be beneficial, and in the future > > there might be open source signatures/profiles ... > > > > > (e.g., by Snort, Suricata, Bro and Kisnet) > > > >s/Kisnet/Kismet/ > >"Snort, Suricata, Bro and Kisnet" reads like a reference -- I had to look > them up to discover that they are IDS software! > > > >But there needs to be some connection between a list of IDS software > systems and "open source signatures/profiles". Perhaps: > > > > Today, black list databases can be beneficial, and in the future > > there might be open source signatures/profiles distributed as part > > of IDS systems (e.g. Snort, Suricata, Bro and Kisnet). > > All good comments, but my recollection was the WG wanted to underscore the > strategy was good for all parties. > Therefore, here's the new paragraph > > > New/ > Today, black list databases can be a beneficial > strategy for all parties involved, but in the future there might be > open Source-provided signature/profiles distributed as part of IDS systems > (e.g., by Snort, Suricata, Bro and Kismet). > / > -- > >There is a need to have a standard envelope (i.e., the format) to > > allow NSFs to use external profiles. > >This is awkward. Perhaps > > There is a need to have a standard format to allow NSFs to use > > external profiles. > > This part hit many discussions. How about > > New/ There is a need to have a standard envelope (i.e., a message format) to > > allow NSFs to use external profiles./ > > >3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger ... > > > > I2NSF controller(s) would manage the changing to the affected > > policies ... > > This could be simplified to "I2NSF controller(s) would change the affected > policies ...". > > New/ I2NSF controller(s) would control any changes to affected policies > (e.g., forwarding and routing, filtering, etc.)./ > > >The I2NSF controls the change (whether others change the policies or not). > > By monitoring the network alerts from DDoS ... > >Probably s/DDoS/DOTS/. > > > > ... I2NSF > > can feed an alerts analytics engine that could recognize attacks so > > the I2NSF can enforce the appropriate policies. > > Here, "I2NSF" is being used as a noun, whereas the previous usage is that > it is an adjective, and "I2NSF controller(s)" would be used. > > New/ > By monitoring the network alerts regarding DDoS attacks (e.g. from DOTS > servers or clients), > the I2NSF controller(s) can feed an alerts analytics engine > that could recognize attacks so the I2NSF can enforce the > appropriate policies. > / > > > > ... provide information to the client ... > > > >I think this is clearer if s/the client/its clients/. "client" is used > with two meanings, one is "customer" (e.g., in the definition of "Bespoke"), > and more commonly as "software client". > If you say "[the controller's] > clients", it is clear that you're using the second meaning. > > New/ DDoS mitigation is enhanced if the provider's network security > controller can monitor, analyze, and investigate the abnormal > events > and provide information to the customer or change the network > configuration automatically > / > > >3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs > > > > There is a need for a controller to distribute various keys to > > distributed NSFs. To distribute various keys, the keys must be > > created and managed. > > >Perhaps combine these as > > > > There is a need for a controller to create, manage, and distribute > > various keys to distributed NSFs. > > I've made this change. > > > > In addition, keys may be used to secure > > the protocol and messages in the core routing infrastructure (see > > [RFC4948]) > > >Probably s/protocol/protocols/. > > > I've made this change. > > > If a device had an abstract key table > > maintained by security services, a device could use these keys for > > routing and seurity devices. > > > >s/seurity/security/ > > > >Typical English usage in this situation is "it could use ..."; because "it" > is the subject of the second clause, it is presupposed to be the same as the > subject of the first clause. > > New sentences: > / If a device had an abstract key table maintained by security services, it > could use these > keys for routing and security devices. / > > > Conceptually, there must be an interface defined for routing/ > > signaling protocols to make requests for automated key management > > when it is being used, and to notify the protocols when keys become > > available in the key table. One potential use of such an interface > > is to manage IPsec security associations on SDN networks. > >I think you need to add a subject in "... and for XXX to notify the > protocols ..." for clarity, the omitted noun could be "interface" or > "protocols". > > Grammatically - I disagree . The clauses "to make request...." and "to > notify" are infinitive clauses which modify the direct object (an interface) > which are linked together in a list. > However, rather than debate this syntax with others - I've changed the > syntax to a cl > > New/ > Conceptually, there must be an interface defined for routing/signaling > protocols > that can: a) make requests for automated key management when it is being > used. and > b) notify the protocols when keys become available in the key table. > / > > > >The last sentence seems redundant, as security associations have been > discussed at the beginning of 3.1.9. Is there a particular reason to point > out IPsec at this point (since many >secured protocols need keys)? > > The WG felt it needed an example here. If it is OK, I'm going to leave > this in for another round of editing. > > > If protocols share > > common mechanisms for authentication (e.g., TCP Authentication > > Option [RFC5925]), then the same mapping may be reused. > > >This sentence starts with "protocols [that] share common mechanisms" > >but then mentions only one protocol. Do you mean > > > If several protocols share a > > common mechanism for authentication (e.g., TCP Authentication > > Option [RFC5925]), then the same mapping may be used for all > > usages of that mechanism. > > > Thank you. I've changed to this sentence. > > > > 3. Automated Key management needs to support both symmetric keys and > > group keys via the abstract key service provided by items 1 and > > 2. > >s/Key/key/ > > --Thank you. > > >I think "via the abstract key service provided by items 1 and 2" is > redundant here. > > It may be redundant, but as I recall it was important to some of the > authors. > -------------- > > 3.2. Challenges Facing Customers > > > o Which critical communications are to be preserved during critical > > events and which hosts are continue service, > > > >"are continue service" seems to be incorrect in some way. > > New/Which critical communications are to be preserved during > critical events and which hosts will continue services over the > network,/ > > > > o What signaling information is passed to a controller that during a > > Distributed Denial of Service in order to ask for mitigation > > services (within the scope DOTS working group), > > "that" should be removed, I think. > > Removed. > > >3.2.2. Today's Control Requests are Vendor Specific > > > > Without a standard technical > > standard interface that provides a clear technical characterization, > > the service provider faces many challenges: > > >Should "standard technical standard interface" be "standard interface" > >or "standardized interface"? > > >Standardized interface. > > No standard technical characterization, APIs, or Interface > >I think you want a colon after this phrase to parallel the other items in > the list. > > Thank you. > > > Managing by scripts de-jour: The current practices rely upon the > > use of scripts that generate other scripts which automatically run > > to upload or download configuration changes, log information and > > other things. These scripts have to be adjusted each time an > > implementation from a different vendor technology is enabled on a > > provider side. > > The phrase "on a provider side" doesn't read well. Perhaps "by a service > provider"? > > 3.3. Lack of Standard Interface to Inject Feedback to NSF > > > The following sub-section describes the problems and challenges > > facing customers and security service providers when some or all of > > the security functions are no longer physically hosted by the > > customer's adminstrative domain. > >s/adminstrative/administrative/ > > Note: Sentence was removed. > > > As more sophisticated threats arise, enterprises, vendors, and > > service providers have to rely on each other to achieve optimal > > protection. Cyber Threat Alliance (CTA, > > http://cyberthreatalliance.org/) is one of those initiatives that aim > > at combining efforts conducted by multiple organizations. > > >This paragraph doesn't fit well in the flow of the text. The second > sentence seems like it's basically a reference, and the link should be put > down in the references. But I think the >point resembles the discussion in > 3.1.7, that you want to enable organizations to pass among themselves new > profiles, which the customers or service providers can insert into NSFs > in > a simple way. Perhaps > > > As more sophisticated threats arise, protection will depend > > on enterprises, vendors, and service providers being able to > > cooperate to develop optimal profiles, e.g., through initiatives > > like [CTA]. > > >and then combine with the paragraph which follows: > > > > The standard interface to provide security profiles to the NSF should > > interwork with the formats which exchange security profiles between > > organizations. > > 3.5. Difficulty to Validate Policies across Multiple Domains > > >As discussed in the previous four sections, both service providers ... > > >Probably s/sections/sub-sections/. > > ... and customers have needs to express policies and profiles ... > > > >s/needs/need/ > > > > This section and the next section (section 3.6) xamine what ... > >s/xamine/examine/ > > > (Have you spell-checked this draft?) > > Not this one. I'm afraid I rushed the -11 out in response to query. I > lived to regret this fact. > > > > > > ... happens in two specific network scnearios: ... > > s/scnearios/scenarios/ > > > a) multi-domain control of > > security devices hosted on virtual and non-virtual ... > >There is a noun missing after "virtual and non-virtual". > > Noun is NSFs > > > Hosted security service may instantiate NSFs in Virtual Machines > > > > > >You probably don't want to capitalize "virtual machines" here. > > Changed. > > > > To set-up this cross-domain service, the security controller must be > > able to communicate with NSFs and/or controllers within its domain > > and across domains to negatiate for the services needed. > > > s/set-up/set up/ ("set up" is a verb (more or less), "set-up" is the > action of setting up or the thing which is set up.) > > The text should be "to set up" an infinitive verb setting up an infinitive > clause, or it can be considered a prepositional phrase "to set up ..." > Anyway, thank you for the editing. > > s/negatiate/negotiate/ > > 3.6. Software-Defined Networks > > > Software-Defined Networks have changed the landscape of data center > > designs by introducing overlay networks deployed over ToR switches > > that connect to a hypervisor. > > >You probably should spell out "ToR switch"; "top of rack switch" is not yet > listed in Wikipedia as a meaning of "ToR". > > > Start here > ----------------- > 4.1. Basic Framework > > > Integrity of the NSF: by ensuring that the NSF is not > > compromised; > > > Isolation: by ensuring the execution of the NSF is self-contained > > for privacy requirements in multi-tenancy scenarios. > > Provenance of NSF: Customers may need to be provided with strict > > guarantees about the origin of the NSF, its status (e.g., > > available, idle, down, and others), and feedback mechanisms so > > that a customer may be able to check that a given NSF or set of > > NSFs properly conform to the the customer's requirements and > > subsequent configuration tasks. > >The punctuation and capitalization is inconsistent between the list items > here. I suggest changing the first two to (more or less)\ > >sentences: > > > > Integrity of the NSF: Ensuring that the NSF is not compromised. > > > > Isolation: Ensuring the execution of the NSF is self-contained > > for privacy requirements in multi-tenancy scenarios. > > > >?Probably s/Provenance of NSF/Provenance of the NSF/. > > > > In order to achieve this, the security controller may collect > > security measurements and share them with an independent and trusted > > third party (via Interface 1) in order to allow for attestation of > > NSF functions using the third party added information. > > > >Would this really be via Interface 1? It looks like Interface 1 only goes > to the customer's client, not a 3rd party service, and it is used for > passing security requests. This is made clearer in the next paragraph, but > it would probably be better to only say that there needs to be an interface > to 3rd parties for services like this, and it may be a variant of Interface > 1 or it may be a distinct interface. > > Dale: While this make be clearer, it was the WGs final comments. I'll see > what the IESG says. > > > >4.2. Access Networks > > > Figure 3 shows how these virtual > > access nodes for different types of customers connect connect through > > virtual access nodes an NSF. > > s/connect connect/connect/ > >The grammar of the sentence needs fixing also somewhere near "nodes an > NSF". > > Sue: Fixed > > > These use cases define the interaction between the operator and the > > vNSFs through automated interfaces, typically by means of > > Business- to-Business (B2B) communications. > >Dale: Is "Business-to-Business (B2B) communications" a technical term? > > It doesn't seem to me to convey any additional information, since most of > the usages envision that NSFs may be provided by outside vendors, so pretty > much any communication with an NSF may be business-to-business > communication. > > New/These use cases define the interaction between the operator and the > vNSFs through automated interfaces which support the business > communications > between customer and provider or between two business entities./ > > > Service Provider: Service requests for policies that protect ... > > > >There isn't a "Service Provider" illustrated in the figure. > >I assume that the Service Provider looks much like the other three cases, > >since those look very much like each other, but some sort of > > illustration should be provided. Especially if the Service Provider > > has further customers (presumably further to the left in the figure), that > would be a more complex architecture. > > Sue: Service Provider added to the network > > > ... may want to get > > their dedicated NSFs (most likely vNSFs) for direct control purposes. > >This is rather informal usage. Perhaps better: > > > ... may want to contract separately for dedicated NSFs ... > > Sue: Thank you - changed. > > > In this case, here are the steps to associate vNSFs to specific > > customers: > >There are two cases discussed in the paragraph before this sentence, > >and it's not obvious which one this sentence is connected to via "In this > case". > >Or does it apply to both? If it applies to the second case only, > >I suggest splitting the last two sentences off as a separate paragraph. > >If this sentence applies to all cases in this subsection, I suggest > removing "In this case". > > Done - split off the second 2 sentences. > > >4.3. Cloud Data Center Scenario > > > > The on-demand, dynamic nature of security service delivery > > essentially encourages that the network security "devices" be in > > software or virtual form factors, rather than in a physical appliance > > form. > > >I think you want to s/form factors/forms/. (The phrase "form factor" > >seems to be abused to mean many things.) > > Done - corrected to "forms" > > > Another example is that IPS/ > > IDS services for investment banking and non-banking traffic may be > > separated for regulatory reasons. > > > Is "investment banking" specific here, or does this statement also apply > to "banking" generally? Or is "non-banking traffic" really > "non-investment-banking traffic" (in which case calling it "other traffic" > is probably better)? > > Sue: Good point. > New / > Another example is that IPS/IDS services which splits traffic into > investment banking traffic and other data traffic to comply with > regulatory restrictions for transfer of investment banking information/ > > >4.3.2. Firewall Policy Deployment Automation > > > > Even though most vendors support similar firewall features, the > > actual rule configuration keywords are different from vendors to > > vendors, making it difficult for automation. > > > >Probably s/actual rule/specific rule/ or even just "specific". > > Sue: > New/ > Even though most vendors support similar firewall features, the > specific rule configuration keywords are different from vendors to > vendors, making it difficult for automation. > / > > 4.3.3. Client-Specific Security Policy in Cloud VPNs > > / Clients of service provider-operated cloud data centers not only need > / to secure Virtual Private Networks (VPNs), but also [X] virtual security > / functions that apply the clients' security policies. > /There's an understood verb at the location marked [X]. I think it's > supposed to be "to secure", and if so, the usage is correct. But it's hard > to read, so I think it would be better to not omit the verb. > > Sue: You are right. The negation in the sentence makes this difficult. > > New /Clients of service provider-operated cloud data centers > need to secure Virtual Private Networks (VPNs) and virtual > security functions that apply the clients' security policies./ > > Now the direct objection into a list (VPNs + virtual security functions). > > > 4.4. Preventing Distributed DoS, Malware and Botnet attacks > > > Many networks such as Internet of > > Things (IoT) networks, Information-Centric Networks (ICN), Content > > Delivery Networks (CDN), Voice over IP packet networks (VoIP), and > > Voice over LTE (VoLTE) are also exposed to such attacks. > > > >This seems to be just a specialization of the preceding sentences. > >Does it add more information? > >(E.g., perhaps there are special considerations for each of these types of > networks, in which case it might be useful to state that.) > > Changed to:/ > Many networks > which carry groups of information (such as Internet of Things (IoT) > networks, > Information-Centric Networks (ICN), Content Delivery Networks (CDN), > Voice over IP packet networks (VoIP), and Voice over LTE (VoLTE)) > are also exposed to such remote attacks. There are many examples of > remote attacks on these networks, but the following examples will illustrate > the > issues. A malware attack on an IoT network which carries sensor readings and > instructions may attempt to > alter the sensor instructions in order to disable a key sensor. > A malware attack VoIP or VoLTE networks is software that attempts to place > unauthorized > long-distance calls. Botnets may overwhelm nodes in ICN and CDN networks so > that > the networks cannot pass critical data. > / > > 4.5. Regulatory and Compliance Security Policies > > >Organizations are not only supposed to protect their networks against > >attacks, but they should also adhere to various industry > >regulations: > >It's probably better to s/should also/must also/! > > Thanks for noticing. > > 7. Security Considerations > > >Having a secure access to control and monitor NSFs is crucial for > > hosted security services. > >Probably s/a secure/secure/. > > > Therefore, proper secure communication > > channels have to be carefully specified for carrying controlling and > > monitoring traffic between the NSFs and their management entity (or > > entities). > > >I think you can condense this to "management entity(ies)", but you probably > should talk to the RFC Editor about it. > > I will ask the RFC Editor about this point. > > > >> In addition, the Flow security policies specified by customers can > >> conflict with providers' internal security policies which may allow > >> unauthorized traffic or unauthorized changes to flow polices (e.g. > >> customers changing flow policies that do not belong to them). > >I don't think you want to capitalize "flow" here. > > Agreed, > > >It's not clear to me what "which may allow unauthorized ..." applies to. > It seems like there's an important issue in just > > In addition, the Flow security policies specified by customers can > > conflict with providers' internal security policies > > > >It seems that solving I2NSF requires a clear understanding of how the > customer's policies and the provider's policies interact. (I would think > something is allowed only if both policies allow it, but the reality may be > more complex.) > > >The rest of the sentence seems redundant given the discussion in the rest > of document. > > > > Therefore, it is crucial to have proper AAA [RFC2904] to authorize > > access to the network and access to the I2NSF management stream. > > > >It seems to me that this is a rather generalized need for I2NSF, and not > connected to the previous sentences. So I would omit "Therefore" > >and put it as a separate paragraph. > > Good catch. > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
