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?
Thank you very much for your continued support to improve the YANG models.
Linda
-----Original Message-----
From: t petch <[email protected]<mailto:[email protected]>>
Sent: Friday, March 25, 2022 12:10 PM
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%2Fdat
a
tracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-i2nsf-compa
r
ison-of-consumer-facing-and-nsf-facing-data-models-00&data=04%7C0
1
%7Clinda.dunbar%40futurewei.com%7Cb8b83f05fa904d406b2008da0e824533%7C
0
fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637838249925611459%7CUnknow
n
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
J
XVCI6Mn0%3D%7C3000&sdata=PpLBu4%2FqvNKaNfjTmtBZQlL6%2B3zjHcx815DA
3
IqzG74%3D&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 protected]<mailto:[email protected]<mailto:[email protected]<mailto:[email protected]>>>
Sent: Monday, March 21, 2022 6:03 AM
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 protected]<mailto:[email protected]<mailto:[email protected]<mailto:[email protected]>>>
On Behalf Of Linda Dunbar
Sent: Tuesday, March 15, 2022 4:44 PM
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]<mailto:[email protected]<mailto:[email protected]<mailto:[email protected]>>>
On Behalf Of t petch
Sent: Wednesday, March 2, 2022 11:20 AM
