Subject: Re: [yang-doctors] [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 25 Jul 2019 10:09:50 -0400

Hi Acee,
Here is the revision letter for the revised draft, reflecting your comments
along with the revised draft:
https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-07

The following things have not been addressed yet due to the time limitation.
- The leveraging of the definitions in RFC 8519 for packet matching.
- The factoring of common types and identities into a common I2NSF types
module.

These two will be reflected in the next revision.

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

Thanks.

Best Regards,
Paul

On Sat, Jun 22, 2019 at 2:03 PM Acee Lindem (acee) <[email-masked]> wrote:

> I have reviewed this document as part of the YANG doctors directorate's
>
> ongoing effort to review all IETF documents being processed by the IESG.
> These
>
> comments were written with the intent of improving the operational aspects
> of the
>
> IETF drafts. Comments that are not addressed in last call may be included
> in AD reviews
>
> during the IESG review.  Document editors and WG chairs should treat these
> comments
>
> just like any other early review comments.
>
>
>
>
>
> Document: draft-ietf-i2nsf-nsf-facing-interface-dm-06
>
> Reviewer: Acee Lindem
>
> Review Date: June 22, 2019
>
> Review Type: Working Group Last Call
>
> Intended Status: Standards Track
>
> Summary: Needs to go back to Working Group for rework and another WGLC
>
>
>
> Modules: "[email-masked]"
>
>
>
> Tech Summary: The model defines different types of I2NSF security policy.
> Each
>
>                              is comprised of an event, a condition, and an
> action. There is
>
>                              significant overlap with other IETF models.
> Within I2NSF, there
>
>                              is repetition of definitions which needs to
> go into a common
>
>                              I2NSF types module.  Additionally, the data
> descriptions were
>
>                               were done quickly and never reviewed or
> edited. I believe
>
>                              it needs to go back to the working group for
> another revision and
>
>                              working group last call.
>
> .
>
>
>
> Major Comments:
>
>
>
>  1. Why don't you leverage the definitions in RFC 8519 for packet matching?
>
>     We don't need all this defined again.
>
>
>
>  2. Date and time are defined in RFC 6991. Why don't those suffice?
>
>
>
>  3. Refer to the intervals as "time-intervals" rather than "time-zones".
>
>     The term "time-zone" has a completely different connotation.
>
>
>
>  4. What the "acl-number"? Also, ACLs are named (RFC 8519). Also, why
>
>     define all the packet matching and then reference an ACL.
>
>
>
>  5. The descriptions are very awkwardly worded and in many cases simply
>
>     repeat the data node or identify description without hyphens. I
>
>     started trying to fix this but it was too much. I'll pass for on
>
>     for some examples. There are enough co-authors and contributors that
>
>     one would expect much better.
>
>
>
>  6. There is overlap of definitions with the I2NSF capabilities draft.
>
>     The common types and identities should be factored into a common
>
>     I2NSF types module.
>
>
>
>  7. The "Security Considerations" in section 8 do not conform to the
>
>     recommended template in
> https://trac.ietf.org/trac/ops/wiki/yang-security-
>
>     guidelines>
>
>
>
>
>
> Minor Comments:
>
>
>
>  1. Section 3.1 should reference RFC8340 rather than attempting to
>
>     include tree diagram formatting semantics.
>
>
>
>  2. "iiprfn" is a poor choice for default model prefix - I suggest
>
>     "nsfintf". It is only one character longer and actually is expands
>
>      to something meaningful.
>
>
>
>  3. RFC 2460 is obsoleted by RFC 8200.
>
>
>
>  4. RFC 791 is the wrong reference for IPv4 TOS. It should be RFC 1394.
>
>
>
>  5. What is the IGRP protocol? I'm familiar with EIGRP but not IGRP.
>
>
>
>  6. What is the skip protocol? Is this about skipping the check? If so,
>
>     why is it needed.
>
>
>
>  7. Reference for IPv6 ICMP should be RFC 2463.
>
>
>
>  8. Why do you include Photuris definitions? Nobody uses this.
>
>
>
>  9. Note that all the keys for all 'config true' lists must be
>
>     unique so your specification in the description as well as
>
>     'mandatory true' are redundant for the 'rules' list. This
>
>     mistake is in other lists as well.
>
>
>
> 10. What is 'during' time?
>
>
>
> 11. What is a "security-grp"? Is this a security-group?
>
>
>
> 12. The module prologue doesn't match the example in Appendix B of
>
>     RFC 8407.
>
>
>
> 13. There needs to be a good definition of absolute and periodic
>
>        time in the descriptions.
>
>
>
> 14. The References do not include all the RFCs referenced by YANG
>
>     model reference statements.
>
>
>
> Nits: Will send diff to authors and i2nsf chairs as example of review that
> should be done on YANG documents prior to sending to YANG doctors.
>
>
>
> Thanks,
> Acee
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> 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: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 29 Jul 2019 15:51:05 +0000

Hi Paul,

The module prologue still doesn’t match the suggested template in RFC 8407 - https://tools.ietf.org/html/rfc8407#appendix-B. Additionally, you didn’t take my suggestion to leverage existing IETF models for packet match specification - https://datatracker.ietf.org/doc/rfc8519/ and date/time specification  - https://www.rfc-editor.org/rfc/rfc8177.txt. Did you look at these?

Thanks,
Acee

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thursday, July 25, 2019 at 10:10 AM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, YANG Doctors <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06

Hi Acee,
Here is the revision letter for the revised draft, reflecting your comments along with the revised draft:
https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-07

- The factoring of common types and identities into a common I2NSF types module.

Thanks.

Best Regards,
Paul

On Sat, Jun 22, 2019 at 2:03 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I have reviewed this document as part of the YANG doctors directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of the
IETF drafts. Comments that are not addressed in last call may be included in AD reviews
during the IESG review.  Document editors and WG chairs should treat these comments
just like any other early review comments.

Tech Summary: The model defines different types of I2NSF security policy. Each
                             is comprised of an event, a condition, and an action. There is
                             significant overlap with other IETF models. Within I2NSF, there
                             is repetition of definitions which needs to go into a common
                             I2NSF types module.  Additionally, the data descriptions were
                              were done quickly and never reviewed or edited. I believe
                             it needs to go back to the working group for another revision and
                             working group last call.
.

Major Comments:

 7. The "Security Considerations" in section 8 do not conform to the
    recommended template in https://trac.ietf.org/trac/ops/wiki/yang-security-
    guidelines>

Minor Comments:

Nits: Will send diff to authors and i2nsf chairs as example of review that should be done on YANG documents prior to sending to YANG doctors.

Thanks,
Acee

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 30 Jul 2019 15:59:03 +0900

Hi Acee,
I will let the module prologue in the next revised draft match the
suggested template in RFC 8407.

I will leverage the existing IETF modiles for packet match specification
and date/time specification
in the next revision.

When the revision is done, I will let you know.

Thanks.

Best Regards,
Paul

On Tue, Jul 30, 2019 at 12:51 AM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Paul,
>
>
>
> The module prologue still doesn’t match the suggested template in RFC 8407
> - https://tools.ietf.org/html/rfc8407#appendix-B. Additionally, you
> didn’t take my suggestion to leverage existing IETF models for packet match
> specification - https://datatracker.ietf.org/doc/rfc8519/ and date/time
> specification  - https://www.rfc-editor.org/rfc/rfc8177.txt. Did you look
> at these?
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
>
>
> *From: *"Mr. Jaehoon Paul Jeong" <[email-masked]>
> *Date: *Thursday, July 25, 2019 at 10:10 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, YANG Doctors <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [I2nsf] YANG Doctors Working Group Last Call Review for
> draft-ietf-i2nsf-nsf-facing-interface-dm-06
>
>
>
> Hi Acee,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Jul 2019 11:57:15 +0000

Thanks Paul – if we can’t use the existing ACL definitions, it would be good to understand why they don’t work.
Thanks,
Acee

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tuesday, July 30, 2019 at 3:00 AM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, YANG Doctors <[email-masked]>, "[email-masked]" <[email-masked]>, "Jingyong (Tim) Kim" <[email-masked]>, "Mr. Jaehoon Paul Jeong" <[email-masked]>
Subject: Re: [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06

Hi Acee,
I will let the module prologue in the next revised draft match the suggested template in RFC 8407.

I will leverage the existing IETF modiles for packet match specification and date/time specification
in the next revision.

Thanks.

Best Regards,
Paul

On Tue, Jul 30, 2019 at 12:51 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,

Thanks,
Acee

From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 25, 2019 at 10:10 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] YANG Doctors Working Group Last Call Review for draft-ietf-i2nsf-nsf-facing-interface-dm-06

Hi Acee,

Thanks.

Best Regards,
Paul

Major Comments:

Minor Comments:

Thanks,
Acee