RE: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11

["Susan Hares" <[e-mail]>]

Dale: 

Thank you for the review.  Please see my comments below. 

Sue 

-----Original Message-----
From: I2nsf [mailto:[e-mail]] On Behalf Of Dale Worley
Sent: Tuesday, March 14, 2017 6:17 PM
To: [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf