Re: [I2nsf] WGLC for draft-ietf-i2nsf-consumer-facing-interface-dm-16

Mon, 21 Mar 2022 04:03:00 -0700 

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, more 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 protected]> On Behalf Of Linda Dunbar
Sent: Tuesday, March 15, 2022 4:44 PM
To: t petch <[email protected]>; Mr. Jaehoon Paul Jeong
<[email protected]>
Cc: [email protected]; Patrick Lingga <[email protected]>; skku-iotlab-
members <[email protected]>
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 protected]> On Behalf Of t petch
Sent: Wednesday, March 2, 2022 11:20 AM
To: Mr. Jaehoon Paul Jeong <[email protected]>
Cc: [email protected]; Patrick Lingga <[email protected]>; skku-iotlab-
members <[email protected]>
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 protected]> 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%2Fdat
atracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-consumer-facing-interface-


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 protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww


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 protected]


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww



.ietf.org%2Fmailman%2Flistinfo%2Fi2nsf&amp;data=04%7C01%7Clinda.dunba



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 protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
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 protected]
https://www.ietf.org/mailman/listinfo/i2nsf

.



_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf

Reply via email to