Subject: Re: [I2nsf] IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm

From: t petch <[email-masked]>
Date: Fri, 1 Apr 2022 12:07:35 +0100

On 28/03/2022 18:23, Linda Dunbar wrote:
> Tom,
>
> As Sue Hares said:
>
>   "The first stage of a yang model is joyous. You decide what goes in.   The
>   second of getting a prototype yang model  implementation is hard work.  The
>   third stage of getting the model approved in the IETF environment is
>   frustrating and painful.    During the second and third stage, most WGs have
>   trouble keeping up the energy - since it is all about the small details of
>   Yang."
>
> All the I2NSF YANG models are at their third stage, with small changes, which is difficult for non-editors to keep up.
> Can you review Paul and his team revisions before they upload revision?

Linda

I continue to see capability as the core I-D which the other I-D are 
then based on and I still see an outstanding DISCUSS against it.  I am 
unclear whether or not capability -26 (or -29 AFAICT) addresses Ben's 
point, that the meaning of a capability is not sufficiently defined in a 
way that will bring interoperability.

As an example, capability specifies icmpv4 and icmpv6 and then uses 
these two, along with DCCP, as base for identity type. consumer-facing 
has a single icmp-message, no differentiation between icmpv4 and icmpv6, 
and derives from it echo and echo-reply, each of which is for both 
icmpv4 and icmpv6.

If a simple box supports icmpv4 only and echo/echo-reply only, what 
capability does that constitute? (How does a user know that DCCP is not 
supported?).

With hindsight, Ben's question is so obvious I wonder how I did not see 
it.  I think that it applies to much of capability (e.g. http, as 
another AD suggested).  I believe that the question can be addressed by 
text, as opposed to revamping the model (such as by taking the identity 
structure to a finer level of detail) but I am not the one with a 
DISCUSS - it is up to the IESG to be satisfied by whatever resolution is 
proposed.  Perhaps they will be satisfied with capability-26 but it is 
now for them to say.

Tom Petch

>
>   Thank you very much for your continued support to improve the YANG models.
>
> Linda
>
> -----Original Message-----
> From: t petch <[email-masked]>
> Sent: Friday, March 25, 2022 12:10 PM
> To: Linda Dunbar <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
> Cc: Patrick Lingga <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
> Subject: Re: IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm
>
> On 25/03/2022 14:39, Linda Dunbar wrote:
>> Tom,
>>
>> At IETF 113 I2NSF session, we had a good discussion of the comparison of draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm, from Top Level YANG Tree, Event, Condition and Action.
>>
>> Here is the summary:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>> tracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-i2nsf-compar
>> ison-of-consumer-facing-and-nsf-facing-data-models-00&amp;data=04%7C01
>> %7Clinda.dunbar%40futurewei.com%7Cb8b83f05fa904d406b2008da0e824533%7C0
>> fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637838249925611459%7CUnknown
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>> XVCI6Mn0%3D%7C3000&amp;sdata=PpLBu4%2FqvNKaNfjTmtBZQlL6%2B3zjHcx815DA3
>> IqzG74%3D&amp;reserved=0
>>
>> Since you didn't join the discussion, can you please look over the comparison and see if they are any issues?
>
> Linda
>
> I did look at the slides when they arrived.
>
> What I deduced some time ago, and see that the current charter specifies, is that it is the Capability Layer that has primacy, that 'Only simple Service Layer policies that are modelled as closely as possible on the Capability Layer are within scope.'  It is then a question not of how close Consumer Facing and Network Facing are (and yes, they are close) but how close each is to Capability.  I note that since I reviewed capability-26 there have been three new versions of that and that the IESG have yet to confirm that the DISCUSS on capability have been resolved; and while -29 has a change log - good - it only gives the changes from -28 (best practice IMHO is have a change log going back to the -00 that precedes adoption) so I have to look at
> -27 to see what it changed and -28 to see what it changed (and no, I do not want a .pdf giving OLD and NEW; a statement that e.g. references to
> RFC4960 have been replaced with references to rfc4960bis I find much quicker to deal with).
>
> So, when the IESG are satisfied with capability I will look at the current version and the others that have come out in-between and then look at the other I-D after that; and yes, the I-D will likely be in the RFC Editor Queue by then:-(.
>
> IN passing, a comment that others have made and which I would endorse is that the authors seem unfamiliar with the usage of 'i.e.' and 'e.g.'
> which in places changes the technical meaning.  I suspect that that will still be the case in the most recent I-D.
>
> Tom Petch
>>
>> Thank you very much,
>>
>> Linda Dunbar
>>
>> -----Original Message-----
>> From: t petch <[email-masked]<mailto:[email-masked]>>
>> Sent: Monday, March 21, 2022 6:03 AM
>> To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>; Linda Dunbar
>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> Cc: Patrick Lingga <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong
>> <[email-masked]<mailto:[email-masked]>>
>> Subject: Re: [I2nsf] WGLC for
>> draft-ietf-i2nsf-consumer-facing-interface-dm-16
>>
>> On 20/03/2022 16:45, Roman Danyliw wrote:
>>> Hi!
>>>
>>> Linda: Thanks sending out this assessment and ending the WGLC.
>>>
>>> WG: In additional to the IPR check, one other thing I will be looking for in the second WGLC of this document is (a) evidence of review by the WG and (b) support by the WG to publish it (irrespective of whether there is charter milestone or not).  There has been very little WG discussion of this document on the mailing list in the last 18 months and no formal meetings with it as a topic.   Most discussions have been between a reduced set of document authors and directorates reviews/IETF LC/IESG balloting feedback.  The last three documents sent to the IESG (-capability-data-model, monitoring-data-model, nsf-facing-interface-dm) have required substantial changes due to AD review, directorate review and IESG Review (to include them all still being blocked with multiple (2-4) DISCUSSes).  I want to make sure that all future documents the WG requests publication on have gotten the needed review in the WG.
>>
>> Roman
>>
>> Yes!
>>
>> I see capability-data-model as being the core I-D from which the others stem (ideally with a common module of YANG and definitions:-).  I was still catching up with the repeated revisions of that when nsf-facing and nsf-monitoring went forward. IMHO the IESG could have had a easier time if the lessons of capability had been applied to the latter two before seeking to progress them; easy to say in hindsight.
>>
>> I think Ben's DISCUSS on capability 2/2/22 are key.  He points out that the level of detail expected is unclear.  What does monitoring on a routing header mean?  All of them, including future ones, any one or what?  Obvious now Ben has said so but I never thought of it. Looking back at RFC8329 I see no mention of routing headers being part of this work (where are the authors of RFC8329 when we need them?).  Ben also comments that a base capability is ambiguous - can it be used per se as in derived-from-or self or only as derived-from?  Likewise the resolution strategies are obvious until Ben points out that they are not defined anywhere that he (or I) can see.  I note that one of them has disappeared from capabiity -26 but like most of the changes to this and the other I-Ds, there is no consensus for this change because there has been no discussion within the WG.
>>
>> This lack of consensus is to me the defining characteristic of the
>> I2NSF WG.  At AD review you asked for expanded definitions in a few
>> cases and got them which seemed fine.  Then a ..art reviewer asks for
>> a whole lot more and gets them.  As I commented, to me this is a lack
>> of familiarity on the part of the ..art reviewer and for most people
>> involved, like you, like me, like other ..art reviewers, the existing
>> definitions are adequate.  And this is a multi-headed hydra because
>> the new text takes the I-D out of line with the other I-D (my bane),
>> with other parts of the same I-D, and, as many have commented, the
>> English often needs attention and so any change to the text is likely
>> to generate further change and may even be unclear or worse.  The
>> changes made generate issues faster than I can point them out so the
>> number of unfixed issues increases exponentially.  Several of Ben's or
>> Lars's textual comments I have marked in my copy as issues to raise
>> when I have raised the larger, mo
> re technical ones; I could have saved Ben and Lars some time (as a WG should do).
>>
>> Out of many such I would highlight the use of 'l4' or 'layer4'.  Some time ago I pointed out that this was unusual in the IETF, 'transport'
>> being more common and this was duly changed in the identity.  A reviewer of nsf-monitoring found the word 'port', used in the context of ipv4/ipv6, ambiguous and suggested 'l4port' which was duly incorporated in some parts of that particular I-D and not in others and not in the other I-Ds (my bane again).  As before, I think the need to qualify 'port' is more of a comment on the reviewer and not on the I-D:-) Had the issue been raised on the list I would have objected!
>>
>> So:
>> - the rate of change on these I-Ds is high (I have yet to catch up
>> with all those that appeared in January and February)
>> - no change has WG consensus because nothing is discussed on the WG
>> list
>> - changes are made to one part of one I-D without being reflected in
>> other parts of that I-D or in the other related I-D
>> - changes lack clarity and so raise further issues requiring change.
>>
>> For me, the root cause is the way of working of the WG, unlike any other I am involved with in that comments made by ...art, by me, do not get reviewed, discussed.  Nothing has consensus.  Coupled with this is the high rate of change induced by the authors - sometimes I can see where the change came from, other times I cannot - and the lack of a clear scope for the work, e.g. a lack of alignment with RFC8329 which ought to be the high-level definition of what this work is about.
>>
>> Tom Petch
>>
>>
>>>
>>> Regards,
>>> Roman
>>>
>>>> -----Original Message-----
>>>> From: I2nsf <[email-masked]<mailto:[email-masked]>> On Behalf Of Linda Dunbar
>>>> Sent: Tuesday, March 15, 2022 4:44 PM
>>>> To: t petch <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong
>>>> <[email-masked]<mailto:[email-masked]>>
>>>> Cc: [email-masked]<mailto:[email-masked]>; Patrick Lingga <[email-masked]<mailto:[email-masked]>>;
>>>> skku-iotlab- members <[email-masked]<mailto:[email-masked]>>
>>>> Subject: Re: [I2nsf] WGLC for
>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-16
>>>>
>>>> I2NSF WG,
>>>>
>>>> Since the comments from Tom Petch haven't been addressed, we can't
>>>> complete the WGLC for draft-ietf-i2nsf-consumer-facing-interface-dm-16.
>>>> Agree with Tom, the WG needs to reach consensus if it is necessary
>>>> for the draft-ietf-i2nsf-consumer-facing-interface-dm to be
>>>> consistent with the draft- ietf-i2nsf-nsf-facing-interface-dm.
>>>>
>>>> Thank you,
>>>> Linda Dunbar
>>>>
>>>> -----Original Message-----
>>>> From: I2nsf <[email-masked]<mailto:[email-masked]>> On Behalf Of t petch
>>>> Sent: Wednesday, March 2, 2022 11:20 AM
>>>> To: Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
>>>> Cc: [email-masked]<mailto:[email-masked]>; Patrick Lingga <[email-masked]<mailto:[email-masked]>>;
>>>> skku-iotlab- members <[email-masked]<mailto:[email-masked]>>
>>>> Subject: Re: [I2nsf] WGLC for
>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-16
>>>>
>>>> On 02/03/2022 14:40, Mr. Jaehoon Paul Jeong wrote:
>>>>> Hi Tom,
>>>>> Patrick and I are finalizing the revision of the NSF-Facing
>>>>> Interface YANG Data Model Draft this week.
>>>>
>>>> If I read it aright, the cut-off for updated I-D for the upcoming
>>>> IETF is next Monday. after which the system is in purdah for a while.
>>>> The IETF website might tell me about the latter (if it had a search
>>>> engine:-)
>>>>
>>>> Tom Petch
>>>>
>>>>
>>>>
>>>>
>>>>> After this revision, we will reflect the comments from IESG on this
>>>>> Consumer-Facing Interface YANG Data Model Draft.
>>>>>
>>>>> Thanks for your comments.
>>>>>
>>>>> Best Regards,
>>>>> Paul
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2022 at 9:31 PM t petch <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>>>
>>>>>> On 17/02/2022 17:00, Linda Dunbar wrote:
>>>>>>> Hello Working Group,
>>>>>>>
>>>>>>> Many thanks to the authors to address all the comments from YANG
>>>>>>> Doctor
>>>>>> review.
>>>>>>>
>>>>>>> This email starts a three-weeks Working Group Last Call for
>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>> d
>>>>>> at
>>>>>> atracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-consumer-facing-interfa
>>>>>> c
>>>>>> e-
>>>>>>
>>>> dm%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C0fd53b96
>>>> 2cbb4
>>>>>>
>>>> 208379608d9fc70f6f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
>>>> C6378
>>>>>>
>>>> 18384373805664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>>>> JQIjoiV2
>>>>>>
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=F7VLxYYqc6kp
>>>> xD3
>>>>>> w15O7Lewbot4zMgkGcozhpKViuJY%3D&amp;reserved=0
>>>>>>
>>>>>> I think that this is premature.  As ever, there is substantial
>>>>>> overlap with other I-D in the set, notably nsf-facing, and, as
>>>>>> ever, the two I-D do things differently which I think can only
>>>>>> confuse.  If there is a reason for the differences, then that
>>>>>> needs calling out IMHO; at the moment it seems arbitrary, such as
>>>>>> which ...art reviewer last
>>>> saw the I-D!
>>>>>>
>>>>>> Further, nsf-facing has just attracted a large number of comments
>>>>>> from IESG Review, many if not most of which apply here.  I think
>>>>>> it wrong for the IESG to be asked to do the same work all over
>>>>>> again so I think that the IESG comments on nsf-facing need
>>>>>> resolving with the IESG first and then the agreed solution - I
>>>>>> expect that most of the comments by the IESG will be accepted - can be incorporated into this I-D.
>>>>>>
>>>>>> Choice of protocols, reference for protocols, way of specifying
>>>>>> ranges of numbers, indeed way of specifying at all, string
>>>>>> language, volte,
>>>>>> RFC793 redundant, all those comments by Alexey on lack of clarity,
>>>>>> Rob's comments on identity descriptions, example labelling and so on.
>>>>>>
>>>>>> Tom Petch
>>>>>>
>>>>>>> This poll runs until March 10, 2022.
>>>>>>>
>>>>>>> We are also polling for knowledge of any undisclosed IPR that
>>>>>>> applies to
>>>>>> this Document, to ensure that IPR has been disclosed in compliance
>>>>>> with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>>>>>> If you are listed as an Author or a Contributor of this Document,
>>>>>>> please
>>>>>> respond to this email and indicate whether or not you are aware of
>>>>>> any relevant undisclosed IPR. The Document won't progress without
>>>>>> answers from all the Authors and Contributors.
>>>>>>>
>>>>>>> If you are not listed as an Author or a Contributor, then please
>>>>>> explicitly respond only if you are aware of any IPR that has not
>>>>>> yet been disclosed in conformance with IETF rules.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> Linda
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> I2nsf mailing list
>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>> F
>>>>>>> ww
>>>>>>>
>>>> w.ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&amp;data=04%7C01%7Clinda.dun
>>>>>>>
>>>> bar%40futurewei.com%7C0fd53b962cbb4208379608d9fc70f6f5%7C0fee8ff2a
>>>> 3b
>>>>>>>
>>>> 240189c753a1d5591fedc%7C1%7C0%7C637818384373805664%7CUnknown
>>>> %7CTWFpb
>>>>>>>
>>>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>>>> M
>>>>>>>
>>>> n0%3D%7C3000&amp;sdata=0WQB3KY3kIBLT9Dl5xemMrTLAMYolmsqtXjkTrjD
>>>> eHk%3
>>>>>>> D&amp;reserved=0
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> I2nsf mailing list
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>>> w
>>>>>>
>>>> .ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&amp;data=04%7C01%7Clinda.dunb
>>>> a
>>>>>>
>>>> r%40futurewei.com%7C0fd53b962cbb4208379608d9fc70f6f5%7C0fee8ff2a3b
>>>> 240
>>>>>>
>>>> 189c753a1d5591fedc%7C1%7C0%7C637818384373805664%7CUnknown%7C
>>>> TWFpbGZsb
>>>>>>
>>>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
>>>> 3D
>>>>>>
>>>> %7C3000&amp;sdata=0WQB3KY3kIBLT9Dl5xemMrTLAMYolmsqtXjkTrjDeHk%3
>>>> D&amp;
>>>>>> reserved=0
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> I2nsf mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>>> w
>>>> .ie%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca57aa6f58f8
>>>> f
>>>> 44e9ff0908da0b2a5814%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
>>>> 7
>>>> 834573760029620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>> V
>>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9AHUtdzTd99i7
>>>> o
>>>> ld6RK0oWhJpJcc4aixyK2rWQzipts%3D&amp;reserved=0
>>>> tf.org%2Fmailman%2Flistinfo%2Fi2nsf&amp;data=04%7C01%7Clinda.dunbar%
>>>> 40futurewei.com%7C0fd53b962cbb4208379608d9fc70f6f5%7C0fee8ff2a3b24
>>>> 0189c753a1d5591fedc%7C1%7C0%7C637818384373805664%7CUnknown%7
>>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>>>> JXVCI6Mn0%3D%7C3000&amp;sdata=0WQB3KY3kIBLT9Dl5xemMrTLAMYolms
>>>> qtXjkTrjDeHk%3D&amp;reserved=0
>>>>
>>>> _______________________________________________
>>>> I2nsf mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>>> w
>>>> .ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&amp;data=04%7C01%7Clinda.dunb
>>>> a
>>>> r%40futurewei.com%7Ca57aa6f58f8f44e9ff0908da0b2a5814%7C0fee8ff2a3b24
>>>> 0
>>>> 189c753a1d5591fedc%7C1%7C0%7C637834573760029620%7CUnknown%7CTWFpbGZs
>>>> b
>>>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>> D
>>>> %7C3000&amp;sdata=PkmIEiLA6kg%2Ff5mXK4YcG8ls%2Bx%2FtGMLbyYdEMk3Ow2g%
>>>> 3
>>>> D&amp;reserved=0
>>> .
>>>
>> .
>>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 1 Apr 2022 21:48:58 +0000

Tom,

Consumer facing Interface commands don't need to differentiate v4 or v6.
For example Kubernetes Cluster Scoped Network Policies use Cluster names, not even the IP addresses:  https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/edit#slide=id.g401c104a3c_0_0

Comments and replies are inserted below:

-----Original Message-----
From: t petch <[email-masked]>
Sent: Friday, April 1, 2022 6:08 AM
To: Linda Dunbar <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Cc: Patrick Lingga <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm

Linda

I continue to see capability as the core I-D which the other I-D are then based on and I still see an outstanding DISCUSS against it.  I am unclear whether or not capability -26 (or -29 AFAICT) addresses Ben's point, that the meaning of a capability is not sufficiently defined in a way that will bring interoperability.
[Linda] Agree with you that capability should be the base that other I-D can references. But for attributes that unique to a specific interface, they should be specified in their corresponding I-D.

As an example, capability specifies icmpv4 and icmpv6 and then uses these two, along with DCCP, as base for identity type. consumer-facing has a single icmp-message, no differentiation between icmpv4 and icmpv6, and derives from it echo and echo-reply, each of which is for both
icmpv4 and icmpv6.
[Linda] Consumer facing Interface commands should be allowed to use more abstract name. Doesn't need to nail down to v4 or v6. It is the security Controller's job to translate to the corresponding icmpv4 or icmpv6 depending on the security function supports ipv4 or IPv6.

If a simple box supports icmpv4 only and echo/echo-reply only, what capability does that constitute? (How does a user know that DCCP is not supported?).
[Linda] At the consumer interface level, users might not need to know if DCCP is supported or now. Not sure why users need to know if DCCP is supported or not?

With hindsight, Ben's question is so obvious I wonder how I did not see it.  I think that it applies to much of capability (e.g. http, as another AD suggested).  I believe that the question can be addressed by text, as opposed to revamping the model (such as by taking the identity structure to a finer level of detail) but I am not the one with a DISCUSS - it is up to the IESG to be satisfied by whatever resolution is proposed.  Perhaps they will be satisfied with capability-26 but it is now for them to say.
[Linda] I hope authors can address the AD's concern.

Thank you very much for helping shaping the data model. Really appreciate your help.
Linda

Tom Petch

> To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Roman Danyliw
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Subject: Re: IETF 113 session in comparing
> draft-ietf-i2nsf-consumer-facing-interface-dm &
> draft-ietf-i2nsf-nsf-facing-interface-dm
>
> What I deduced some time ago, and see that the current charter
> specifies, is that it is the Capability Layer that has primacy, that
> 'Only simple Service Layer policies that are modelled as closely as
> possible on the Capability Layer are within scope.'  It is then a
> question not of how close Consumer Facing and Network Facing are (and
> yes, they are close) but how close each is to Capability.  I note that
> since I reviewed capability-26 there have been three new versions of
> that and that the IESG have yet to confirm that the DISCUSS on
> capability have been resolved; and while -29 has a change log - good -
> it only gives the changes from -28 (best practice IMHO is have a
> change log going back to the -00 that precedes adoption) so I have to
> look at
> -27 to see what it changed and -28 to see what it changed (and no, I
> do not want a .pdf giving OLD and NEW; a statement that e.g.
> references to
>> From: t petch <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>> To: Roman Danyliw <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>; Linda Dunbar
>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>;
>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
>> Cc: Patrick Lingga
>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>; Mr.
>> Jaehoon Paul Jeong
>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>> number of unfixed issues increases exponentially.  Several of Ben's
>> or Lars's textual comments I have marked in my copy as issues to
>> raise when I have raised the larger, mo
>>>> From: I2nsf <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>>>> On Behalf Of Linda Dunbar
>>>> To: t petch <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>; Mr.
>>>> Jaehoon Paul Jeong
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>>>> Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>; Patrick Lingga
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>;
>>>> skku-iotlab- members
>>>> <[email-masked]<mailto:skku-iotlab-members@go
>>>> oglegroups.com>>
>>>> From: I2nsf <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>>>> On Behalf Of t petch
>>>> To: Mr. Jaehoon Paul Jeong
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
>>>> Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>; Patrick Lingga
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>;
>>>> skku-iotlab- members
>>>> <[email-masked]<mailto:skku-iotlab-members@go
>>>> oglegroups.com>>
>>>>> After this revision, we will reflect the comments from IESG on
>>>>> this Consumer-Facing Interface YANG Data Model Draft.
>>>>>
>>>>> On Wed, Mar 2, 2022 at 9:31 PM t petch <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>
>>>>>>
>>>>>> RFC793 redundant, all those comments by Alexey on lack of
>>>>>> clarity, Rob's comments on identity descriptions, example labelling and so on.
>>>>>>
>>>>>> Tom Petch
>>>>>>
>>>>>> this Document, to ensure that IPR has been disclosed in
>>>>>> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>>>>>> If you are listed as an Author or a Contributor of this
>>>>>>> Document, please
>>>>>> respond to this email and indicate whether or not you are aware
>>>>>> of any relevant undisclosed IPR. The Document won't progress
>>>>>> without answers from all the Authors and Contributors.
>>>>>>>
>>>>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
>>>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
>>>>>>
>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 2 Apr 2022 23:25:37 +0900

Hi Linda and Tom,

Linda's answers are accurate, so I totally agree with her.

We can support the abstract ICMP for ICMPv4, ICMPv6 or both in
a high-level policy in Consumer-Facing Interface (CFI).
For example, we specify ICMP echo traffic in a policy in CFI.
The version of ICMP depends on the network version(s).
---

For Ben's last comment for his DISCUSS on the I2NSF Capability I-D -26
(
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-29
),
I respond to Ben and Paul Wouter as a new AD as follows:
---------------------------------------------------------------------------
//Ben's comment on I-D -26 version
I do, however, still feel that it is most important to have a conversation
about what the actual goals of the model are in terms of what type of
semantics we expect to be assigned to the different capabilities that a
NSF might claim.  Only once that topic is understood would we be in a
position to make concrete suggestions for the best way to express those
intended semantics in YANG.
---------------------------------------------------------------------------

The 1st actual goal of this model is for a Developer's Management System
to specify what capabilities an NSF has for a security service and to
register those capabilities of the NSF with Security Controller
through Registration Interface.

The 2nd goal of this model is for Security Controller to search for an
appropriate NSF for a requested security service for a high-level
security policy from I2NSF User through Registration Interface.
Refer to I2NSF Registration Interface I-D:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-15

With this clarification, please let me know your concrete suggestions
for the best way to express those intended semantics in YANG.

Thanks.

Best Regards,
Paul

On Sat, Apr 2, 2022 at 6:49 AM Linda Dunbar <[email-masked]>
wrote:

> For example Kubernetes Cluster Scoped Network Policies use Cluster names,
> not even the IP addresses:
> *https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/edit#slide=id.g401c104a3c_0_0*
> <https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/edit#slide=id.g401c104a3c_0_0>
>
> > All the I2NSF YANG models are at their third stage, with small changes,
> which is difficult for non-editors to keep up.
> I continue to see capability as the core I-D which the other I-D are then
> based on and I still see an outstanding DISCUSS against it.  I am unclear
> whether or not capability -26 (or -29 AFAICT) addresses Ben's point, that
> the meaning of a capability is not sufficiently defined in a way that will
> bring interoperability.
> [Linda] Agree with you that capability should be the base that other I-D
> can references. But for attributes that unique to a specific interface,
> they should be specified in their corresponding I-D.
>
>
> As an example, capability specifies icmpv4 and icmpv6 and then uses these
> two, along with DCCP, as base for identity type. consumer-facing has a
> single icmp-message, no differentiation between icmpv4 and icmpv6, and
> derives from it echo and echo-reply, each of which is for both
> icmpv4 and icmpv6.
> [Linda] Consumer facing Interface commands should be allowed to use more
> abstract name. Doesn’t need to nail down to v4 or v6. It is the security
> Controller’s job to translate to the corresponding icmpv4 or icmpv6
> depending on the security function supports ipv4 or IPv6.
>
> [Linda] At the consumer interface level, users might not need to know if
> DCCP is supported or now. Not sure why users need to know if DCCP is
> supported or not?
>
>
> it.  I think that it applies to much of capability (e.g. http, as another
> AD suggested).  I believe that the question can be addressed by text, as
> opposed to revamping the model (such as by taking the identity structure to
> a finer level of detail) but I am not the one with a DISCUSS - it is up to
> the IESG to be satisfied by whatever resolution is proposed.  Perhaps they
> will be satisfied with capability-26 but it is now for them to say.
> [Linda] I hope authors can address the AD’s concern.
>
> >> At IETF 113 I2NSF session, we had a good discussion of the comparison
> of draft-ietf-i2nsf-consumer-facing-interface-dm &
> draft-ietf-i2nsf-nsf-facing-interface-dm, from Top Level YANG Tree, Event,
> Condition and Action.
> >>
> >> Here is the summary:
> >> Since you didn't join the discussion, can you please look over the
> comparison and see if they are any issues?
> >
> > Linda
> >
> > So, when the IESG are satisfied with capability I will look at the
> current version and the others that have come out in-between and then look
> at the other I-D after that; and yes, the I-D will likely be in the RFC
> Editor Queue by then:-(.
> >
> > IN passing, a comment that others have made and which I would endorse is
> that the authors seem unfamiliar with the usage of 'i.e.' and 'e.g.'
> > which in places changes the technical meaning.  I suspect that that will
> still be the case in the most recent I-D.
> >
> > Tom Petch
> >>
> >> Thank you very much,
> >>
> >> Linda Dunbar
> >>
> >> <[email-masked]<mailto:[email-masked]>>; Mr.
> >> Jaehoon Paul Jeong
> >>> WG: In additional to the IPR check, one other thing I will be looking
> for in the second WGLC of this document is (a) evidence of review by the WG
> and (b) support by the WG to publish it (irrespective of whether there is
> charter milestone or not).  There has been very little WG discussion of
> this document on the mailing list in the last 18 months and no formal
> meetings with it as a topic.   Most discussions have been between a reduced
> set of document authors and directorates reviews/IETF LC/IESG balloting
> feedback.  The last three documents sent to the IESG
> (-capability-data-model, monitoring-data-model, nsf-facing-interface-dm)
> have required substantial changes due to AD review, directorate review and
> IESG Review (to include them all still being blocked with multiple (2-4)
> DISCUSSes).  I want to make sure that all future documents the WG requests
> publication on have gotten the needed review in the WG.
> >>
> >> Roman
> >>
> >> Yes!
> >>
> >> I see capability-data-model as being the core I-D from which the others
> stem (ideally with a common module of YANG and definitions:-).  I was still
> catching up with the repeated revisions of that when nsf-facing and
> nsf-monitoring went forward. IMHO the IESG could have had a easier time if
> the lessons of capability had been applied to the latter two before seeking
> to progress them; easy to say in hindsight.
> >>
> >> I think Ben's DISCUSS on capability 2/2/22 are key.  He points out that
> the level of detail expected is unclear.  What does monitoring on a routing
> header mean?  All of them, including future ones, any one or what?  Obvious
> now Ben has said so but I never thought of it. Looking back at RFC8329 I
> see no mention of routing headers being part of this work (where are the
> authors of RFC8329 when we need them?).  Ben also comments that a base
> capability is ambiguous - can it be used per se as in derived-from-or self
> or only as derived-from?  Likewise the resolution strategies are obvious
> until Ben points out that they are not defined anywhere that he (or I) can
> see.  I note that one of them has disappeared from capabiity -26 but like
> most of the changes to this and the other I-Ds, there is no consensus for
> this change because there has been no discussion within the WG.
> >>
> >> Out of many such I would highlight the use of 'l4' or 'layer4'.  Some
> time ago I pointed out that this was unusual in the IETF, 'transport'
> >> being more common and this was duly changed in the identity.  A
> reviewer of nsf-monitoring found the word 'port', used in the context of
> ipv4/ipv6, ambiguous and suggested 'l4port' which was duly incorporated in
> some parts of that particular I-D and not in others and not in the other
> I-Ds (my bane again).  As before, I think the need to qualify 'port' is
> more of a comment on the reviewer and not on the I-D:-) Had the issue been
> raised on the list I would have objected!
> >>
> >> So:
> >> For me, the root cause is the way of working of the WG, unlike any
> other I am involved with in that comments made by ...art, by me, do not get
> reviewed, discussed.  Nothing has consensus.  Coupled with this is the high
> rate of change induced by the authors - sometimes I can see where the
> change came from, other times I cannot - and the lack of a clear scope for
> the work, e.g. a lack of alignment with RFC8329 which ought to be the
> high-level definition of what this work is about.
> >>
> >> Tom Petch
> >>
> >>
> >>>
> >>> Regards,
> >>> Roman
> >>>
> >>>> Cc: [email-masked]<mailto:[email-masked]>; Patrick Lingga
> >>>> <[email-masked]<mailto:[email-masked]>>;
> >>>> skku-iotlab- members
> >>>> complete the WGLC for
> draft-ietf-i2nsf-consumer-facing-interface-dm-16.
> >>>> Cc: [email-masked]<mailto:[email-masked]>; Patrick Lingga
> >>>> <[email-masked]<mailto:[email-masked]>>;
> >>>> skku-iotlab- members
> >>>>> On Wed, Mar 2, 2022 at 9:31 PM t petch <
> [email-masked]<mailto:[email-masked]>> wrote:
> >>>>>
> >>>>>>

---

From: t petch <[email-masked]>
Date: Mon, 4 Apr 2022 08:11:47 +0100

Linda

I still do not see an answer to my uncertainty about the meaning of a 
capability e.g. if a box supports some 'type' or 'code' for icmpv4 (and 
nothing for icmpv6 or DCCP), then what capability does that constitute, 
what can it advertise as supporting?  What will appear in the leaf-list 
in condition-capabilities as imported by the I-D registration-interface?

Or, turning the question around, how much must it support to justify 
advertising the YANG 'type' capability (which is derived from a base of 
icmpv4, icmpv6 or DCCP)?

My concern, perhaps unwarranted, is that the resolution of the DISCUSS 
for capability may have a ripple effect on the YANG identity in other 
I-D, such as consumer-facing.

Tom Petch

>>>>> Sent: Wednesday, March 2, 2022 11:20 AM
<snip>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 4 Apr 2022 14:35:25 +0000

Tom,

Answers to your questions are inserted below in Blue:

-----Original Message-----
From: t petch <[email-masked]>
Sent: Monday, April 4, 2022 2:12 AM
To: Linda Dunbar <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Cc: Patrick Lingga <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: IETF 113 session in comparing draft-ietf-i2nsf-consumer-facing-interface-dm & draft-ietf-i2nsf-nsf-facing-interface-dm

On 01/04/2022 22:48, Linda Dunbar wrote:
> For example Kubernetes Cluster Scoped Network Policies use Cluster
> names, not even the IP addresses:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .google.com%2Fpresentation%2Fd%2F1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvx
> N5v2BaY%2Fedit%23slide%3Did.g401c104a3c_0_0&amp;data=04%7C01%7Clinda.d
> unbar%40futurewei.com%7Ca05e3fa9884c459f464c08da161ad60a%7C0fee8ff2a3b
> 240189c753a1d5591fedc%7C1%7C0%7C637846601766141559%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000&amp;sdata=WkQCW%2B1YTBRt4igP4ts7UE3ZUN7o2boxdG2rYus55xA%3D&am
> p;reserved=0
>

Linda

I still do not see an answer to my uncertainty about the meaning of a capability e.g. if a box supports some 'type' or 'code' for icmpv4 (and nothing for icmpv6 or DCCP), then what capability does that constitute, what can it advertise as supporting?  What will appear in the leaf-list in condition-capabilities as imported by the I-D registration-interface?

[Linda] https://datatracker.ietf.org/doc/rfc8192/ has good description of why need "Capability" of each NSF. In a nutshell, to provide effective and competitive solutions and services, security service providers may need to utilize multiple security functions from various vendors to enforce the security policies desired by  their customers.
There are many virtual security functions by different vendors available to be deployed to achieve "Customer" desired policy. The "Security Controller" can choose the NSFs with the desired "Capability" per "Customer Interface" specified policies for a service.

Or, turning the question around, how much must it support to justify advertising the YANG 'type' capability (which is derived from a base of icmpv4, icmpv6 or DCCP)?
[Linda] https://datatracker.ietf.org/doc/draft-yang-i2nsf-security-policy-translation/ describes the mechanism to translate "Customer Interface" security requests to the actual policies to NSF.

My concern, perhaps unwarranted, is that the resolution of the DISCUSS for capability may have a ripple effect on the YANG identity in other I-D, such as consumer-facing.

[Linda] Thank you very much for helping improving the draft quality. All your questions definitely has helped shaping up the drafts.

Tom Petch

> has a single icmp-message, no differentiation between icmpv4 and
> icmpv6, and derives from it echo and echo-reply, each of which is for
> both
> icmpv4 and icmpv6.
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
>>> t
>>> a
>>> tracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-i2nsf-comp
>>> a
>>> r
>>> ison-of-consumer-facing-and-nsf-facing-data-models-00&amp;data=04%7C
>>> 0
>>> 1
>>> %7Clinda.dunbar%40futurewei.com%7Cb8b83f05fa904d406b2008da0e824533%7
>>> C
>>> 0
>>> fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637838249925611459%7CUnkno
>>> w
>>> n
>>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>> C
>>> J
>>> XVCI6Mn0%3D%7C3000&amp;sdata=PpLBu4%2FqvNKaNfjTmtBZQlL6%2B3zjHcx815D
>>> A
>>> 3
>>> IqzG74%3D&amp;reserved=0
>>>
>> yes, they are close) but how close each is to Capability.  I note
>> that since I reviewed capability-26 there have been three new
>> versions of that and that the IESG have yet to confirm that the
>> DISCUSS on capability have been resolved; and while -29 has a change
>> log - good - it only gives the changes from -28 (best practice IMHO
>> is have a change log going back to the -00 that precedes adoption) so
>> I have to look at
>>> From: t petch
>>> <[email-masked]<mailto:[email-masked]<mailto:ietfa@btconne
>>> ct.com<mailto:[email-masked]>>>
>>> cases and got them which seemed fine.  Then a ..art reviewer asks
>>> for a whole lot more and gets them.  As I commented, to me this is a
>>> lack of familiarity on the part of the ..art reviewer and for most
>>> people involved, like you, like me, like other ..art reviewers, the
>>> existing definitions are adequate.  And this is a multi-headed hydra
>>> because the new text takes the I-D out of line with the other I-D
>>> (my bane), with other parts of the same I-D, and, as many have
>>> commented, the English often needs attention and so any change to
>>> the text is likely to generate further change and may even be
>>> unclear or worse.  The changes made generate issues faster than I
>>> can point them out so the number of unfixed issues increases
>>> exponentially.  Several of Ben's or Lars's textual comments I have
>>> marked in my copy as issues to raise when I have raised the larger,
>>> mo
>>>>> From: I2nsf
>>>>> <[email-masked]<mailto:[email-masked]<mailto:i2nsf
>>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>>
>>>>> From: I2nsf
>>>>> <[email-masked]<mailto:[email-masked]<mailto:i2nsf
>>>>> [email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>>
>>>>> On Behalf Of t petch
<snip>