Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Sun, 06 September 2020 11:26 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 41A2F3A0CE8; Sun, 6 Sep 2020 04:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BUNi8Wg24fPe; Sun, 6 Sep 2020 04:26:52 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 D93043A0100; Sun, 6 Sep 2020 04:26:51 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id u8so550806lff.1; Sun, 06 Sep 2020 04:26:51 -0700 (PDT)
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=g+EQ+/bmDxtVITGHyawXUFdgWLhhianQbCYE122CC8s=; b=FUkYwWYo5jwC0HyvRiGNz+ufGEK7ldVAXkR8PVfwBxOKN/Fs4eZ/8le0Oq3oEA2qJw 0a/O6djfPhlrTiWuhcTJ2dpbQEnyD9eKYRO5q1LpEadDC8u959jZGbdN0TVhxVVFe2Ja 0ZBms8ZVRSK1luVxqAhfcI9YRXQWkkEjfdG3CTL9TbQ+lMXXQPWDtkfSIgNsVMj7pjHE y1HEZKpcgWxASkQOL/5B99Oj4fpEmrl4jOD5qfFTOsOS5tKXQBT6mvANU/IQXXf3Aa9F e+V7p5xn9qKows4/Qghd3iPCooAJiJ9liJDdscxg5dbSXe7DMfQIvwK7Qt7CGWIcO98X WPjw==
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=g+EQ+/bmDxtVITGHyawXUFdgWLhhianQbCYE122CC8s=; b=RgCxHOIcQuqZCT9C88GWMo5exhsbutk3VjtIsT4IgCG3ScyHGdyAm2fdvXzmWhWqMK Z+kWqsv9coffA7mFc0X4wvSQC/Y+sFUsad+9KRnUt6RNmXvE8zU1MRbHVc700MNvmhIz kaTQSFzGN47iTSXDypIsk2jmz2d73Sp9jERYv+mD4U20u9wwaTXbGrpNSs8d25r987Re Xqx+82UT5WHFtgkoYGBfajzvslmT6xqdPF8oXey6YVWpsouxeuTviqJhBif4SF87ikdy DgYTkfwBVryuJ1m3dwtNHTy0f9u8DknKGfrlADyMYWmTePWi82JfXAhqckYWsIW1nSBa URWg==
X-Gm-Message-State: AOAM530cYFcyQKg3aHOvvZQliFA47Rn00uQL6Tu0RjT0S9w2tY1a+/YA kSjmaIe9hJUHRBN6CBykQtWmfFv9odUS4CZ733A=
X-Google-Smtp-Source: ABdhPJzkMYxrn2YrTDOe/NpToX1TNnV27PwqXHjVF3/4PhZxRmEB9mSvE9gnsx1yr0IROIzGWV9VRhUyComqbvFRuGE=
X-Received: by 2002:a19:5f5e:: with SMTP id a30mr8016714lfj.64.1599391609493; Sun, 06 Sep 2020 04:26:49 -0700 (PDT)
MIME-Version: 1.0
References: <157349122063.7571.1978842562243958252@ietfa.amsl.com> <CAPK2Dexgk81Saufei3z67E4XZg=LLra1HdTUWU-kU33Pj_o+eg@mail.gmail.com> <CAPK2DeyWEzR6Qy6HPURnKp481mH=y+3O2xpLBS9kLc1MPbcjBg@mail.gmail.com> <44A4E4A8-AF9A-47AF-A31A-8AAACAF0A6BA@tail-f.com> <CAPK2Dey7GzzAWh8AeKA8e5Ng8skxZBf1SYKGLyuatpZDJ+YPWQ@mail.gmail.com> <5F117489.6060709@btconnect.com> <5F118663.8010707@btconnect.com> <CAPK2DezHCBfCRbNXr7=B=8=R-1g-REz_JEc6iRUt_U4sgXNd=Q@mail.gmail.com> <5F49315F.70303@btconnect.com>
In-Reply-To: <5F49315F.70303@btconnect.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Sun, 06 Sep 2020 20:26:09 +0900
Message-ID: <CAPK2DewSGeDPBNzEC_yAY+iL_E9P1CW1uZOYm_A+1e9tcMopOA@mail.gmail.com>
To: tom petch <daedulus@btconnect.com>
Cc: Jan Lindblad <janl@tail-f.com>, YANG Doctors <yang-doctors@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/alternative; boundary="000000000000bd9df605aea360a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/_6Afo04ahGGnkydIHws-tFEDi88>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07
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: Sun, 06 Sep 2020 11:26:58 -0000

Hi Tom,
I have reflected your two comments in the revision:
https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-11

Please see my answers inline below.

On Sat, Aug 29, 2020 at 1:31 AM tom petch <daedulus@btconnect.com> wrote:

> On 28/08/2020 14:46, Mr. Jaehoon Paul Jeong wrote:
> > Hi Tom,
> > I have addressed all your comments in the following revision:
> >
> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-10
> >
>
> Inline
>
>
> > Here are my answers for your comments:
> >
> ------------------------------------------------------------------------------------
> > Some more minor tweaks
> > s.5.1 /gorup/group/
> > => The replacement is done.
> >
> > YANG module
> >
> > WG Chairs are not usually listed in the module - they used to be
> > => The information of WG Chairs is removed.
> >
> > description is a bit terse - some quote the Abstract
> > => I have improved the descriptions in the YANG module.
> >
> > YARA, SNORT, SURICATA would benefit from references; they are not ones I
> > see in TLS or SSH!
> > => I have added the references to YARA, SNORT, and SURICATA.
> >
> > typedef time I see in RFC6991bis
> > => I used typedef time in RFC6991bis.
>
> See my other note about importing from 6991-bis rather than from 6991
>

 => I replaced 6991 with 6991-bis.

>
> >
> > does the ipv6 addresss ever need the interface?
> > => Yes, the IPv6 address needs the CFI interface.
> >     I added an XML example using IPv6 addresses.
> >
> > start/end ipv4/ipv6 could do with a must end > start
> > => I put a description that an IPv4/IPv6 start address is lower than
> >     an IPv4/IPv6 end address.
> >
> >     "A range match for IPv4 addresses is provided.  Note that the
> >      start IPv4 address must be lower than the end IPv4 address.";
> >
> >     "A range match for IPv6 addresses is provided.  Note that the
> >      start IPv6 address must be lower than the end IPv4 address.";
> >
> > geo-ip could do with a reference
> > => I added a reference to geo-ip as follows.
> >     RFC8805: A Format for Self-Published IP Geolocation Feeds
> >
> > s.9.1 221.159 is not a documentation address - see RFC5737
> > => I used documentation addresses for IPv4 from RFC5737.
> >     I also used documentation addresses for IPv6 from RFC3849.
>
> good
>
>
> > IESG often expect an ipv6 example alongside ipv4
> > => I added an XML example using IPv6 addresses in Figure 19.
> >
> > s.12 Registrant should be IESG
> > => I modified the IANA considerations section such that Registrant is the
> > IESG.
> >
> > prefix is not that of the module
> > => I am not sure of this comment. I think we use the correct prefix of
> > "cfi-policy".
> >     CFI stands for Consumer-Facing Interface.
>
> Yes indeed you do - my mistake.  What I had intended to say, looking at
> other NSF modules, was that there are a number of NSF modules and the
> chosen prefix have nothing in common.  Bear in mind that all the YANG
> modules get mixed up together on the box so while the prefix need to be
> compact, there is something to be said for them to be meaningful so
> RTGWG modules could start rt... or MPLS ones mpls... or PCE ones pce..
> and so on so you could consider using a prefix of nsf... such as nsfcfi
> or if there are several such nsfcfi-p or some such (but that is getting
> a bit long)
>

 => I used nsfcfi for the prefix for Consumer-Facing Interface (CFI).

     Thanks.

     Best Regards,
     Paul


>
> Tom Petch
>
> >
> ------------------------------------------------------------------------------------
> >
> > Thanks for your valuable comments.
> >
> > Best Regards,
> > Paul
> >
> > On Fri, Jul 17, 2020 at 8:07 PM tom petch <daedulus@btconnect.com>
> wrote:
> >
> >> On 17/07/2020 10:51, tom petch wrote:
> >>> On 11/07/2020 08:44, Mr. Jaehoon Paul Jeong wrote:
> >>>> Hi Jan and Tom,
> >>>> I have revised our I2NSF Consumer-Facing Interface (CFI) Data Model
> >> Draft
> >>>> according to both your comments.
> >>>>
> >>>> Jan,
> >>>> I attach the revised draft and the revision letter to explain how I
> have
> >>>> reflected your comments one by one.
> >>>>
> >>>> Tom,
> >>>> the references to RFC inside our YANG module cannot be cited in my I-D
> >>>> XML
> >>>> file, so I cannot include them
> >>>> in Normative References.
> >>>
> >>> Yes you can and in fact you must:-)
> >>> You can put anything you want to in Normative References with a
> >>> corresponding [RFC0913] in the text part of the I-D so you add Section
> >>> 8.1 "This YANG module imports from [RFC6991], ... and makes reference
> to
> >>> [RFC0854], [RFC0913], ......"
> >>>
> >>> Note that all import must have a reference clause and the referenced
> >>> work must appear in Normative References; same technique applies.
> >>
> >> Some more minor tweaks
> >>
> >> s.5.1 /gorup/group/
> >>
> >> YANG module
> >>
> >> WG Chairs are not usually listed in the module - they used to be
> >>
> >> descripton is a bit terse - some quote the Abstract
> >>
> >> YARA, SNORT, SURICATA would benefit from references; they are not ones I
> >> see in TLS or SSH!
> >>
> >> typedef time I see in RFC6991bis
> >>
> >> does the ipv6 addresss ever need the interface?
> >>
> >> start/end ipv4/ipv6 could do with a must end > start
> >>
> >> geo-ip could do with a reference
> >>
> >> s.9.1  221.159 is not a documentation address - see RFC5737
> >>
> >> IESG often expect an ipv6 example alongside ipv4
> >>
> >> s.12 Registrant should be IESG
> >>
> >> prefix is not that of the module
> >>
> >>
> >> Tom Petch
> >>
> >>
> >>> Tom Petch
> >>>
> >>>>
> >>>> Also, the choice of the prefix  is i2nsf-cfi.
> >>>>
> >>>> I put "Note: This section is informative" for Sections 7 and 10, which
> >>>> include XML configuration examples.
> >>>>
> >>>> If you have further comments, please let me know by July 12, 2020, in
> >>>> EST.
> >>>> If possible, I want to post this revision on July 13, 2020 after
> >>>> reflecting
> >>>> your further comments on the revision.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Paul
> >>>>
> >>>>
> >>>> On Fri, Mar 20, 2020 at 2:25 AM Jan Lindblad <janl@tail-f.com> wrote:
> >>>>
> >>>>> Paul,
> >>>>>
> >>>>> Thank you for all your work with the module, and for the reminder for
> >> me
> >>>>> to verify all the changes.
> >>>>>
> >>>>> I am afraid I think the module is still not ready for last call, even
> >> if
> >>>>> it is better shape than ever thanks to your efforts. I went through
> the
> >>>>> module from top to bottom, so this is sorted in order of appearance.
> >>>>>
> >>>>> Line 107-204: The following identities are declared in the module,
> but
> >>>>> never referenced. They should either have a common base with
> >>>>> something, or
> >>>>> be referenced somewhere. If not, why are they defined here? They
> >>>>> currently
> >>>>> serve no purpose in this YANG module.
> >>>>>     identity ddos {
> >>>>>     identity enforce-type {
> >>>>>     identity admin {
> >>>>>     identity time {
> >>>>>
> >>>>> Line 377: Defining a custom date-and-time type seems odd. You should
> >>>>> probably use one that has already been defined
> >>>>>     typedef date-and-time {
> >>>>>
> >>>>> Line 513: The leaf represents the name of a user, but the format is
> >>>>> undefined. What should be the format for the string value? How would
> >>>>> a user
> >>>>> know what to configure here? Email addresses? If implementation
> >>>>> dependent,
> >>>>> say so.
> >>>>>       leaf name {
> >>>>>         type string;
> >>>>>         description
> >>>>>           "This represents the name of a user.";
> >>>>>
> >>>>> Line 518: If no IP address information is specified for the
> user-group,
> >>>>> what happens then? Is the user access accepted, rejected, or
> >>>>> something else?
> >>>>>       uses ip-address-info;
> >>>>>
> >>>>> Line 658: Key leaf declared mandatory. All keys are mandatory, so
> >>>>> mandatory is not needed on this leaf.
> >>>>>       leaf policy-name {
> >>>>>         type string;
> >>>>>         mandatory true;
> >>>>>
> >>>>> Line 664: Users mentioned in the owners-ref should have full CRUD
> >>>>> privileges to the policy. But what about everyone else? Should they
> >> have
> >>>>> R(ead) privileges? Can anyone create new policies? If not, who can?
> If
> >>>>> someone creates a policy, but does not mention his own name among
> >> owners
> >>>>> (e.g. misspells or does not get the format right), he will not be
> >>>>> able to
> >>>>> modify or remove the policy. If no owner is mentioned, then noone
> can.
> >>>>>       uses owners-ref;
> >>>>>
> >>>>> Line 673: Key leaf declared mandatory. All keys are mandatory, so
> >>>>> mandatory is not needed on this leaf.
> >>>>>           leaf rule-name {
> >>>>>             type string;
> >>>>>             mandatory true;
> >>>>>
> >>>>> Line 682: Users mentioned in the owners-ref should have full CRUD
> >>>>> privileges to the rule. But what about everyone else? Should they
> have
> >>>>> R(ead) privileges? Can anyone create new rules, or only those that
> have
> >>>>> full CRUD privileges for the policy? If someone creates a rule, but
> >> does
> >>>>> not mention his own name among owners (e.g. misspells or does not get
> >>>>> the
> >>>>> format right), he will not be able to modify or remove the rule.
> >>>>>       uses owners-ref;
> >>>>>
> >>>>> Line 697: Choice enforce-type has a description that I can't
> >> understand.
> >>>>> What does this mean?
> >>>>>             choice enforce-type {
> >>>>>               description
> >>>>>                 "There are two different enforcement types;
> >>>>>                 admin, and time.
> >>>>>                 It cannot be allowed to configure
> >>>>>                 admin=='time' or enforce-time=='admin'.";
> >>>>>
> >>>>> Line 703: In case of enforce-type admin (whatever that means), a
> string
> >>>>> value needs to be configured. What are the valid values for this
> leaf?
> >>>>>               case enforce-admin {
> >>>>>                 leaf admin {
> >>>>>                   type string;
> >>>>>                   description
> >>>>>                     "This represents the enforcement type
> >>>>>                     based on admin's decision.";
> >>>>>
> >>>>> Line 711: In case of enforce-type time, three times can be
> configured.
> >>>>> What is the relation between enforce-time, and the other two
> >>>>> (begin-time,
> >>>>> end-time)?
> >>>>>               case time {
> >>>>>                 container time-information {
> >>>>>                   description
> >>>>>                     "The begin-time and end-time information
> >>>>>                     when the security rule should be applied.";
> >>>>>                   leaf enforce-time {
> >>>>>                     type date-and-time;
> >>>>>                     description
> >>>>>                       "The enforcement type is time-enforced.";
> >>>>>                   }
> >>>>>                   leaf begin-time {
> >>>>>                     type date-and-time;
> >>>>>                     description
> >>>>>                       "This is start time for time zone";
> >>>>>                   }
> >>>>>                   leaf end-time {
> >>>>>                     type date-and-time;
> >>>>>                     description
> >>>>>                       "This is end time for time zone";
> >>>>>                   }
> >>>>>
> >>>>> Furthermore, the locally defined date-and-time type used includes
> both
> >> a
> >>>>> date and time, which seems to be at odds with the example
> >>>>> configurations in
> >>>>> the draft. Example 9.2:
> >>>>>     <rules>
> >>>>>       <rule>
> >>>>>
>  <rule-name>block_access_to_sns_during_office_hours</rule-name>
> >>>>>         <event>
> >>>>>           <time-information>
> >>>>>             <begin-time>2020-03-11T09:00:00.00Z</begin-time>
> >>>>>             <end-time>2020-03-11T18:00:00.00Z</end-time>
> >>>>>
> >>>>> In the example, the rule-name
> "block_access_to_sns_during_office_hours
> >> "
> >>>>> suggests that the begin-time and end-time should be times of day
> >> between
> >>>>> which the policy should be enforced. E.g. every day between 9.00 and
> >>>>> 18.00.
> >>>>> If that is a valid use case, using a time type with a date doesn't
> make
> >>>>> much sense. In the context of the policy that repeats "daily", how
> >>>>> should
> >>>>> the start date-and-time value "2020-03-11T09:00:00.00Z " be
> >> interpreted?
> >>>>> What if it was "monthly"?
> >>>>>
> >>>>> Line 736: In the frequency leaf, the enumeration value only-once is
> for
> >>>>> rules that don't repeat. But how long do they apply? A single
> packet? A
> >>>>> single time the rule is triggered? How does a user know if the rule
> is
> >>>>> still in effect, i.e. if the "once" has happened or not?
> >>>>>                 enum only-once {
> >>>>>
> >>>>> Line 835: Maybe it's just my limited understanding of how
> threat-feeds
> >>>>> work, but I wonder i this construct with source and destinations for
> >>>>> threat
> >>>>> feeds is meaningful?
> >>>>>             container threat-feed-condition {
> >>>>>               description
> >>>>>                 "The condition based on the threat-feed
> information.";
> >>>>>               leaf-list source {
> >>>>>                 type leafref {
> >>>>>                   path
> >>>>> "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
> >>>>>                 }
> >>>>>               description
> >>>>>                 "Describes the threat-feed condition source.";
> >>>>>               }
> >>>>>               leaf dest-target {
> >>>>>                 type leafref {
> >>>>>                   path
> >>>>> "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
> >>>>>                 }
> >>>>>               description
> >>>>>                 "Describes the threat-feed condition destination.";
> >>>>>
> >>>>> Line 920: Location groups can be configured, but there seems to be no
> >>>>> references to them. How are they supposed to be used?
> >>>>>         list location-group{
> >>>>>           key "name";
> >>>>>           uses location-group;
> >>>>>
> >>>>> Line 931: Regarding point 16.1 in your revision letter, you say "We
> >>>>> think
> >>>>> list type of threat-feed-list can be configured more than one feed of
> >>>>> the
> >>>>> same type". I'm afraid that is not the case with the current YANG
> >>>>> model. If
> >>>>> you do wish to allow more than one threat-feed-list for the same
> >>>>> threat-feed-type, you need to add an additional key to your
> >>>>> threat-feed-list.
> >>>>>         list threat-feed-list {
> >>>>>           key "name";
> >>>>>           description
> >>>>>             "There can be a single or multiple number of
> >>>>>             threat-feeds.";
> >>>>>           uses threat-feed-info;
> >>>>>
> >>>>> ...
> >>>>>     grouping threat-feed-info {
> >>>>>       description
> >>>>>         "This is the grouping for the threat-feed-list";
> >>>>>       leaf name {
> >>>>>         type identityref {
> >>>>>           base threat-feed-type;
> >>>>>
> >>>>>
> >>>>> Generally, the indentation in the module is much improved. Some lines
> >>>>> are
> >>>>> still a bit off, however, so I would recommend using a tool that
> >> indents
> >>>>> consistently.
> >>>>>
> >>>>> Generally, I also wonder whether there has been any discussion with
> >>>>> implementors around the admin security model proposed here. As noted
> >>>>> before, it's a bit different from everything else I have seen. Is it
> >>>>> well
> >>>>> thought through? Do implementors feel this is doable and user
> friendly?
> >>>>> Currently there are no examples involving owner. Perhaps an example
> >> that
> >>>>> sheds some light over how different users create, modify and see the
> >>>>> various rules would shed some light over this.
> >>>>>
> >>>>> Best Regards,
> >>>>> /jan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18 Mar 2020, at 18:41, Mr. Jaehoon Paul Jeong
> >>>>> <jaehoon.paul@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Hi Jan,
> >>>>> Could you update the state of YANGDOCTORS Last Call Review on
> >>>>> I2NSF Consumer-Facing Interface YANG Data Model  if the updates are
> >> fine
> >>>>> to you?
> >>>>>
> >>>>>
> >>>>>
> >>
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/
> >>>>>
> >>>>>
> >>>>> I think your comments are all addressed in this version.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Best Regards,
> >>>>> Paul
> >>>>>
> >>>>> On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong <
> >>>>> jaehoon.paul@gmail.com> wrote:
> >>>>>
> >>>>>> Hi Jan,
> >>>>>> We authors have addressed your comments with the revision:
> >>>>>>
> >>>>>>
> >>
> https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-08
> >>>>>>
> >>>>>>
> >>>>>> I attach a revision letter to explain how to respond to your
> comments.
> >>>>>>
> >>>>>> If you have further comments, please let me know.
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Paul
> >>>>>>
> >>>>>> On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker <
> >>>>>> noreply@ietf.org> wrote:
> >>>>>>
> >>>>>>> Reviewer: Jan Lindblad
> >>>>>>> Review result: Almost Ready
> >>>>>>>
> >>>>>>> This is my YD review of
> >>>>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-07. I
> >>>>>>> have previously reviewed the -05 revision (~end June). I find the
> new
> >>>>>>> revision
> >>>>>>> much improved, but still with much to discuss. I will call this
> >>>>>>> "almost
> >>>>>>> ready".
> >>>>>>>
> >>>>>>> Generally speaking, I think the YANG module lacks the precision and
> >>>>>>> descriptions needed to foster interoperability. The examples at the
> >>>>>>> end
> >>>>>>> are
> >>>>>>> very enlightening however, and compensate for much of that, but
> their
> >>>>>>> informal
> >>>>>>> nature can never replace proper YANG. The module usage needs to be
> >>>>>>> mostly clear
> >>>>>>> from the module itself.
> >>>>>>>
> >>>>>>> The management access control model proposed here is, even with its
> >>>>>>> latest
> >>>>>>> adaptation towards NACM, is still quite different from NACM
> author's
> >>>>>>> original
> >>>>>>> ideas. I will therefore bring this use case up in the NETMOD WG for
> >>>>>>> discussion.
> >>>>>>>
> >>>>>>> 1. Network access control principles
> >>>>>>>
> >>>>>>> Network access control is about which users are able to use the
> >>>>>>> network
> >>>>>>> being
> >>>>>>> managed, for example connect to facebook. The purpose of the NSF
> >>>>>>> module
> >>>>>>> is to
> >>>>>>> control this access. This version of the YANG module is now based
> on
> >> a
> >>>>>>> list of
> >>>>>>> policies.
> >>>>>>>
> >>>>>>> Each policy has a list of rules. Each rule has an event --
> >>>>>>> condition --
> >>>>>>> action
> >>>>>>> triplet. This resembles traditional firewall management, which is a
> >>>>>>> good
> >>>>>>> thing,
> >>>>>>> because that concept is stable and much tried. This allows
> >>>>>>> operators to
> >>>>>>> create
> >>>>>>> lists of rules in this style:
> >>>>>>>
> >>>>>>> if pkt.x == 1: drop                     // Rule 1
> >>>>>>> elif pkt.y > 2: alert                   // Rule 2
> >>>>>>> elif pkt.z == 10: pass          // Rule 3
> >>>>>>> else: drop                              // Rule 4
> >>>>>>>
> >>>>>>> This pattern relies heavily on the ability to control the order of
> >> the
> >>>>>>> rules.
> >>>>>>> The current model relies on the alphabetical sorting of names rules
> >>>>>>> for
> >>>>>>> the
> >>>>>>> ordering. The YANG trick I would recommend to give operators the
> >>>>>>> ability
> >>>>>>> to
> >>>>>>> insert and move rules as they wish is to add ordered-by user on the
> >>>>>>> list:
> >>>>>>>
> >>>>>>>       list rule {
> >>>>>>>         ordered-by user;  // <== Add this line
> >>>>>>>         leaf rule-name {
> >>>>>>>
> >>>>>>> Nothing is said about what the system should do in case policies
> >>>>>>> conflict. What
> >>>>>>> if one policy says pass, the other drop for the same packet? Please
> >>>>>>> clarify.
> >>>>>>> What should happen to packets that do not match any of the
> policies?
> >>>>>>>
> >>>>>>> This module also assumes that all users in the operator's
> >> organization
> >>>>>>> are
> >>>>>>> listed in one or more NACM groups (e.g. "employees"). That wasn't
> >>>>>>> really
> >>>>>>> the
> >>>>>>> NACM authors' original intent. Even if this could be made to work
> >>>>>>> maybe,
> >>>>>>> there
> >>>>>>> is no strong reason to repurpose the NACM group concept for user
> >>>>>>> network
> >>>>>>> access
> >>>>>>> purposes. It could easily be modeled differently. So in the cases
> >>>>>>> where
> >>>>>>> there
> >>>>>>> are leafrefs to NACM groups when dealing with network access rather
> >>>>>>> than
> >>>>>>> management access, don't use NACM groups.
> >>>>>>>
> >>>>>>>                   leaf src-target {
> >>>>>>>                     type leafref {
> >>>>>>>                       path
> >>>>>>> /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;  //
> >>>>>>>                       <== Point to some other list of network users
> >>>>>>>
> >>>>>>> 2. Management access control principles
> >>>>>>>
> >>>>>>> Management access control is about which users are able to
> >>>>>>> configure/run
> >>>>>>> actions/the policies and rules. IMO, the most controversial aspect
> of
> >>>>>>> this
> >>>>>>> module has always been its new and creative management access
> control
> >>>>>>> model. In
> >>>>>>> this revision, the management principles have been remodeled
> >>>>>>> greatly to
> >>>>>>> fit in
> >>>>>>> with NACM. I find this redesign very promising, but the result is
> >>>>>>> still
> >>>>>>> not
> >>>>>>> quite ready for publication.
> >>>>>>>
> >>>>>>> The point where integration with NACM concepts is important is when
> >> it
> >>>>>>> comes to
> >>>>>>> allow some users to CRUD the NSF policies and rules themselves.
> >>>>>>> There is
> >>>>>>> now a
> >>>>>>> leaf-list "owners" on each policy and rule which point to a list of
> >>>>>>> NACM
> >>>>>>> groups. My understanding is that the idea is that the NSF module
> >>>>>>> should
> >>>>>>> be seen
> >>>>>>> as a service model that translate high level ownership information
> to
> >>>>>>> specific
> >>>>>>> NACM rules. It would be good to mention these ideas somewhere in
> >>>>>>> the NSF
> >>>>>>> document.
> >>>>>>>
> >>>>>>>     leaf-list owners {
> >>>>>>>       type leafref {
> >>>>>>>         path /nacm:nacm/nacm:groups/nacm:group/nacm:name;
> >>>>>>>
> >>>>>>> I expect the intent is that any user listed in a NACM group
> >>>>>>> mentioned in
> >>>>>>> the
> >>>>>>> owners list would get full CRUD privileges for the contents of the
> >>>>>>> rule
> >>>>>>> the
> >>>>>>> owners leaf sits on. That is never spelled out anywhere, however.
> >>>>>>>
> >>>>>>> It is a little less clear how leaf-list owners on policy objects
> >>>>>>> should
> >>>>>>> be
> >>>>>>> handled. Should owners listed on a policy object get full CRUD
> powers
> >>>>>>> over the
> >>>>>>> entire policy, including all the rules inside? Or would they need
> >>>>>>> to be
> >>>>>>> listed
> >>>>>>> on the rules as well? Not clear. Is the intent that users not
> >>>>>>> listed on
> >>>>>>> the
> >>>>>>> policy object are unable to create new rules, but to be able to
> >> update
> >>>>>>> rules
> >>>>>>> they are listed as owners of, if any?
> >>>>>>>
> >>>>>>> Who is allowed to create new policy objects? Should users that are
> >> not
> >>>>>>> owners
> >>>>>>> get read access to all the policies and rules?
> >>>>>>>
> >>>>>>> Finally, there is an "owner" leaf on each rule with an identityref
> >>>>>>> allowing
> >>>>>>> operators to configure a role name like dept-head or sec-admin. It
> is
> >>>>>>> marked
> >>>>>>> mandatory, but never included in any of the examples at the end of
> >> the
> >>>>>>> document. This makes me think this may be a remnant from bygone
> >>>>>>> times and
> >>>>>>> should be removed from the YANG. If not, an explanation of how to
> use
> >>>>>>> this
> >>>>>>> leaf, and how it interacts with "owners" needs to be added, and the
> >>>>>>> examples
> >>>>>>> updated.
> >>>>>>>
> >>>>>>> 3. leafrefs crosspointing between policy instances
> >>>>>>>
> >>>>>>> There are six leafrefs that point to various objects inside a
> policy,
> >>>>>>> e.g. a
> >>>>>>> rule condition pointing to a device group name. None of them
> restrict
> >>>>>>> what can
> >>>>>>> be pointed to so that only names within the current policy are
> >>>>>>> valid. It
> >>>>>>> is
> >>>>>>> therefore possible to configure the name of a device group defined
> >>>>>>> in a
> >>>>>>> different policy. I suspect this is not the intention. In order to
> >>>>>>> restrict the
> >>>>>>> leafrefs to the same policy, the following predicate can be added:
> >>>>>>>
> >>>>>>>                   leaf-list src-target {
> >>>>>>>                     type leafref {
> >>>>>>>                     path
> >>>>>>>
> >>>>>>>
> >>
> "/i2nsf-cfi-policy[policy-name=current()/../../../../../policy-name]/endpoint-group/device-group/name";
> >>>>>>>
> >>>>>>>                      // <== Add predicate
> >>>>>>>
> >>>>>>> 4. Mandatory to implement all events, conditions, actions
> >>>>>>>
> >>>>>>> Each rule is defined with a choice of different events (admin,
> time),
> >>>>>>> conditions (firewall, ddos, custom, threat-feed) and actions (pass,
> >>>>>>> drop,
> >>>>>>> alert, mirror, ...). Is the intent that all of these options should
> >> be
> >>>>>>> mandatory to implement? The current model requires this. Also,
> >>>>>>> would it
> >>>>>>> make
> >>>>>>> sense to allow additional mechanisms here? If so, it may be good to
> >>>>>>> explain to
> >>>>>>> readers how the set of choices and identities can be extended by
> >>>>>>> implementations.
> >>>>>>>
> >>>>>>> 5. Optional and mandatory elements
> >>>>>>>
> >>>>>>> In this revision of the module, 8 leafs have been marked
> mandatory. A
> >>>>>>> few of
> >>>>>>> them are list keys, which are conventionally not marked mandatory,
> >>>>>>> since
> >>>>>>> list
> >>>>>>> keys are always mandatory. A few others are skipped in the XML
> >>>>>>> examples
> >>>>>>> at the
> >>>>>>> end of the NSF document, which makes me believe they might not
> >>>>>>> really be
> >>>>>>> mandatory after all.
> >>>>>>>
> >>>>>>> Three leafs have a default, but most leafs are left optional
> >>>>>>> without any
> >>>>>>> default. In many cases I think I understand what it means to not
> set
> >> a
> >>>>>>> leaf,
> >>>>>>> but with the ones listed here, I don't think it clear at all.
> >>>>>>> Either add
> >>>>>>> a
> >>>>>>> default to make it clear, make them mandatory if they should be, or
> >>>>>>> explain in
> >>>>>>> the leaf description what happens if not set.
> >>>>>>>
> >>>>>>> 493: leaf-list name
> >>>>>>> 513: leaf-list protocol
> >>>>>>> 531: leaf geo-ip-ipv4
> >>>>>>> 541: leaf continent
> >>>>>>> 562: leaf feed-server-ipv4
> >>>>>>> 585: leaf payload-description
> >>>>>>> 590: leaf-list content
> >>>>>>> 600: leaf-list owners
> >>>>>>> 870: leaf method
> >>>>>>>
> >>>>>>> 6. Indentation
> >>>>>>>
> >>>>>>> The YANG indentation is mostly wrong. Run the YANG text through
> >>>>>>> pyang or
> >>>>>>> some
> >>>>>>> other tool that can indent the content correctly before you put it
> >>>>>>> into a
> >>>>>>> document.
> >>>>>>>
> >>>>>>> 7. YANG element naming
> >>>>>>>
> >>>>>>> The YANG convention is to not have lists on the top level in the
> YANG
> >>>>>>> module,
> >>>>>>> but to surround lists with a container. The surrounding container
> >>>>>>> often
> >>>>>>> has a
> >>>>>>> name in the plural and the list in singluar, like this
> >>>>>>>
> >>>>>>> container interfaces {
> >>>>>>>       list interface {
> >>>>>>>
> >>>>>>> To better fit into the world of IETF YANG modules, I'd recommend
> >>>>>>> turning
> >>>>>>> the
> >>>>>>> top level list i2nsf-cfi-policy into this instead:
> >>>>>>>
> >>>>>>> container i2nsf-cfi-policies {
> >>>>>>>       list policy {
> >>>>>>>
> >>>>>>> Further down, I would change container rule to rules:
> >>>>>>>
> >>>>>>> container rules {
> >>>>>>>       list rule {
> >>>>>>>
> >>>>>>> Finally, it is customary to not repeat the names of parent object
> >>>>>>> in the
> >>>>>>> names
> >>>>>>> of elements. For example, in the following:
> >>>>>>>
> >>>>>>> list threat-feed-list
> >>>>>>>       leaf feed-name
> >>>>>>>       leaf feed-server-ipv4
> >>>>>>>       leaf feed-server-ipv6
> >>>>>>>       leaf feed-description
> >>>>>>>
> >>>>>>> all the leafs should normally not repeat "feed-". Just leaf name,
> >> leaf
> >>>>>>> server-ipv4, leaf server-ipv6, leaf description. There are many
> more
> >>>>>>> examples
> >>>>>>> of this throughout the module.
> >>>>>>>
> >>>>>>> The condition choice has many containers with a single leaf inside
> >>>>>>> (e.g.
> >>>>>>> ddos-source). Their purpose is rather unclear to me. Remove?
> >>>>>>>
> >>>>>>>                 container ddos-source {
> >>>>>>>                   description
> >>>>>>>                   "This represents the source.";
> >>>>>>>                   leaf-list src-target {
> >>>>>>>
> >>>>>>> Also, I find the name "src-target" rather confusing. How about
> >>>>>>> "source"?
> >>>>>>>
> >>>>>>> 8. No date leaf
> >>>>>>>
> >>>>>>> The draft text near fig 2 talks about a date leaf. There is no date
> >>>>>>> object in
> >>>>>>> this revision of te YANG.
> >>>>>>>
> >>>>>>> "Date:  Date when this object was created or last modified"
> >>>>>>>
> >>>>>>> 9. leaf owner
> >>>>>>>
> >>>>>>> Near fig.3 leaf Owner is mentioned. Is this leaf still current?
> >>>>>>>
> >>>>>>> "Owner: This field contains the onwer of the rule.  For example,
> >>>>>>>                the person who created it, and eligible for
> modifying
> >>>>>>> it."
> >>>>>>>
> >>>>>>> 10. leaf packet-per-second
> >>>>>>>
> >>>>>>> This is now modeled as uint16. Is this future proof? Many packet
> >> flows
> >>>>>>> on the
> >>>>>>> internet exceed 64k pps.
> >>>>>>>
> >>>>>>> 11. container custon-source
> >>>>>>>
> >>>>>>> Misspelled. Should be custom-source
> >>>>>>>
> >>>>>>> 12. identity ddos
> >>>>>>>
> >>>>>>> Is ddos a malware file-type? This is not exactly in line with my
> >>>>>>> intuition.
> >>>>>>>
> >>>>>>> 13. identity protocol-type
> >>>>>>>
> >>>>>>> There are other modules that already define protocol-types. Would
> >>>>>>> it be
> >>>>>>> worth
> >>>>>>> reusing one of them?
> >>>>>>>
> >>>>>>> 14. identity palo-alto
> >>>>>>>
> >>>>>>> Is it a good IETF practice to list vendor names in modules? Can we
> >>>>>>> consider
> >>>>>>> this a protocol name? Is there perhaps an RFC/specification name
> >>>>>>> for it
> >>>>>>> that we
> >>>>>>> could reference instead?
> >>>>>>>
> >>>>>>> 15. grouping ipsec-based-method
> >>>>>>>
> >>>>>>> This grouping contains a list which allows listing none of, either
> >>>>>>> of or
> >>>>>>> both
> >>>>>>> of ipsecike and ikeless. Are all valid configurations?
> >>>>>>>
> >>>>>>> 16. leaf feed-name
> >>>>>>>
> >>>>>>> This leaf is the key in a list, which makes it possible to have at
> >>>>>>> most
> >>>>>>> one
> >>>>>>> feed of each type. If it would make sense to configure more than
> one
> >>>>>>> feed of
> >>>>>>> the same type, the YANG needs to be updated here.
> >>>>>>>
> >>>>>>> 17. leaf-list content
> >>>>>>>
> >>>>>>> This leaflist is of type string. What is the format of this string?
> >>>>>>> Does
> >>>>>>> the
> >>>>>>> name refer to something?
> >>>>>>>
> >>>>>>> 18. Event types
> >>>>>>>
> >>>>>>> container event has a choice between enforce-admin and time
> >>>>>>> alternatives. Each
> >>>>>>> of those choices have a leaf that allows the operator to configure
> an
> >>>>>>> identityref to an enforce-type value. What does that mean? What
> >>>>>>> would it
> >>>>>>> mean
> >>>>>>> if an operator configured admin == 'time' (or enforce-time ==
> >>>>>>> 'admin')?
> >>>>>>>
> >>>>>>> 19. leaf begin-time, end-time
> >>>>>>>
> >>>>>>> >From the examples, it can be seen that these are meant to be a
> >>>>>>> time of
> >>>>>>> day
> >>>>>>> values. Currently they are modeled as yang:date-and-time, which
> means
> >>>>>>> they are
> >>>>>>> a concrete time a specific day, e.g. 2019-11-11T16:07. This needs
> >>>>>>> to be
> >>>>>>> changed
> >>>>>>> in order to be what the modeler intended. Perhaps like this:
> >>>>>>>
> >>>>>>> typedef time-of-day {
> >>>>>>>       type string {
> >>>>>>>           pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]';
> >>>>>>>       }
> >>>>>>> }
> >>>>>>>
> >>>>>>> 20. leaf frequency
> >>>>>>>
> >>>>>>> This leaf is now modeled properly from a YANG perspective. But what
> >>>>>>> does
> >>>>>>> it
> >>>>>>> mean? If this leaf is set to 'once-only', what exactly will happen
> >>>>>>> only
> >>>>>>> once?
> >>>>>>> Please write a description that explains this.
> >>>>>>>
> >>>>>>> 21. Example in Fig.17
> >>>>>>>
> >>>>>>> The example contains XML that refers to
> "endpoint-group/user-group".
> >>>>>>> There is
> >>>>>>> no such element in the YANG.
> >>>>>>>
> >>>>>>> <endpoint-group
> >>>>>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
> >>>>>>>     <user-group>
> >>>>>>>
> >>>>>>> Furthermore, there is nothing called range-ip-address,
> >>>>>>> start-ip-address,
> >>>>>>> end-ip-address. They are called range-ipv4-address,
> >>>>>>> start-ipv4-address,
> >>>>>>> end-ipv4-address.
> >>>>>>>
> >>>>>>>       <range-ip-address>
> >>>>>>>         <start-ip-address>221.159.112.1</start-ip-address>
> >>>>>>>         <end-ip-address>221.159.112.90</end-ip-address>
> >>>>>>>       </range-ip-address>
> >>>>>>>
> >>>>>>> Finally, there must not be any xmlns attribute on an closing XML
> >>>>>>> tag. So
> >>>>>>>
> >>>>>>> </endpoint-group
> >>>>>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
> >>>>>>>
> >>>>>>> should be
> >>>>>>>
> >>>>>>> </endpoint-group>
> >>>>>>>
> >>>>>>> This happens in several of the examples.
> >>>>>>>
> >>>>>>> 22. Example in Fig.18
> >>>>>>>
> >>>>>>> There is no element called policy any more. It's now
> >> i2nsf-cfi-policy.
> >>>>>>>
> >>>>>>>      <policy
> >> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
> >>>>>>>        <policy-name>security_policy_for_blocking_sns</policy-name>
> >>>>>>>
> >>>>>>> The rules are modeled in a container and list, both by the name
> >>>>>>> rule. So
> >>>>>>> there
> >>>>>>> needs to be two <rule> tags.
> >>>>>>>
> >>>>>>>        <rule>
> >>>>>>>
> >>   <rule-name>block_access_to_sns_during_office_hours</rule-name>
> >>>>>>>
> >>>>>>> The security-event element is marked mandatory in the YANG, but
> >>>>>>> missing
> >>>>>>> in the
> >>>>>>> example. The times given below may be what is intended, but do not
> >>>>>>> match
> >>>>>>> the
> >>>>>>> date format for the type used (which include a date, etc).
> >>>>>>>
> >>>>>>>          <event>
> >>>>>>>            <time-information>
> >>>>>>>              <begin-time>09:00</begin-time>
> >>>>>>>              <end-time>18:00</end-time>
> >>>>>>>            </time-information>
> >>>>>>>          </event>
> >>>>>>>
> >>>>>>> Since the example is not mentioning leaf frequency, it will have
> the
> >>>>>>> value
> >>>>>>> 'once-only'. Maybe explain what that means in the context of the
> >>>>>>> example?
> >>>>>>>
> >>>>>>> The condition/firewall-condition says the src-target is mandatory
> and
> >>>>>>> dest-target optional, exactly like below.
> >>>>>>> condition/custom-destination/dest-target is mandatory and
> >>>>>>> src-target is
> >>>>>>> optional, exactly like below. Is this pure luck, or is there a
> >> logical
> >>>>>>> explanation why exactly those should be mandatory, and the example
> >> use
> >>>>>>> precisely those?
> >>>>>>>
> >>>>>>>          <condition>
> >>>>>>>            <firewall-condition>
> >>>>>>>              <source-target>
> >>>>>>>                <src-target>employees</src-target>
> >>>>>>>              </source-target>
> >>>>>>>            </firewall-condition>
> >>>>>>>            <custom-condition>
> >>>>>>>              <destination-target>
> >>>>>>>                <dest-target>sns-websites</dest-target>
> >>>>>>>              </destination-target>
> >>>>>>>            </custom-condition>
> >>>>>>>
> >>>>>>> The current YANG model does not allow setting both a
> >>>>>>> firewall-condition
> >>>>>>> and
> >>>>>>> custom-condition. If that should be allowed, the model needs to
> >>>>>>> change.
> >>>>>>> Should
> >>>>>>> it be possible to have multiple firewall- or other conditions? That
> >> is
> >>>>>>> not
> >>>>>>> currently possible.
> >>>>>>>
> >>>>>>> This example leaves out the mandatory leaf owner. Is that a sign
> >>>>>>> that it
> >>>>>>> should
> >>>>>>> not be mandatory, or perhaps not exist at all?
> >>>>>>>
> >>>>>>> 23. Example in Fig.19
> >>>>>>>
> >>>>>>> This example lists a firewall-condition with no src-target, which
> is
> >>>>>>> mandatory.
> >>>>>>>
> >>>>>>>         <firewall-condition>
> >>>>>>>           <destination-target>
> >>>>>>>             <dest-target>employees</dest-target>
> >>>>>>>           </destination-target>
> >>>>>>>         </firewall-condition>
> >>>>>>>
> >>>>>>> Under condition, there is a container rate-limit with a leaf
> >>>>>>> packet-per-second.
> >>>>>>> Is this a trigger value for the condition, or is it an actual limit
> >>>>>>> that
> >>>>>>> the
> >>>>>>> system is expected to enforce? If it's a trigger, it may be good to
> >>>>>>> find
> >>>>>>> a
> >>>>>>> clearer name. If it's enforced, it's placement under condition is
> >>>>>>> deceiving.
> >>>>>>>
> >>>>>>> If a rule's action is set to 'rate-limit', to which rate will it be
> >>>>>>> limited?
> >>>>>>>
> >>>>>>> 24. Security Considerations
> >>>>>>>
> >>>>>>> Section 10 in the NSF document under review is the Security
> >>>>>>> Considerations. I
> >>>>>>> think it would make sense to mention something about the management
> >>>>>>> access
> >>>>>>> control mechanism here, and its relation to NACM.
> >>>>>>>
> >>>>>>> (End of list)
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> I2nsf mailing list
> >>>>>>> I2nsf@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/i2nsf
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> ===========================
> >>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D.
> >>>>>> Associate Professor
> >>>>>> Department of Software
> >>>>>> 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>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ===========================
> >>>>> Mr. Jaehoon (Paul) Jeong, Ph.D.
> >>>>> Associate Professor
> >>>>> Department of Software
> >>>>> 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>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >
> >
>


-- 
===========================
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>