On 26/03/2022 14:49, Susan Hares wrote:
Tom:
Thank you for this feedback.
This error in the model comes from the initial assumptions during the start
of these models. This error was a design choice in the early models based
on the flux in Yang during the NMDA model discussions. Benoit's advice was
to try to get models out and then revise. The security ADs were pushing
the working group to make progress. Benoit and the security ADs wanted
progress. The tenant of "replication" works in that environment.
Versioning in Yang models is still a work in progress. This round of
versioning is still not complex enough for BGP policy modeling. (And
IMHO/AFAIK Open Config Yang modeling is behind IETF modeling in complex
versioning).
Therefore, the error in that advice to Linda Dunbar and Paul Jeong is mine.
Paul, his co-authors, and his students have done the best possible based on
that advice. Time has moved on in both realms (netmod) and security. The
current security ADs were not privy to these pieces of advice.
Would you suggest going back to square-1 to rework each of these models?
If so, should this be the first order of work?
Sue,
No way! I look at OPSAWG who decided to produce four modules, got two
to RFC and then realised how much was in common between the four so
produced a common and used that in the latter two and will use it in any
revision of the first two RFC. Here you have five about to become RFC
as-is, but I would like to see prioritised a 'common' - definitions,
explanations (e.g. PMR, 'Base identity...', Capability, ...) and YANG
(identity!), based on those five, as the next work item after that so
that the I-D for the next YANG model - I see several have been suggested
- after that can use that work, as can those that come after that; as
could any revisions of the first five.
It is ironic, really. In general, in YANG, I see a lot of 'common' YANG
type, YANG grouping within a module which add nothing but complexity to
the module and whatever the opposite of ease-of-use is; and I then see
YANG doctors comment that this grouping is only used once, get rid of
it; which I agree with. So, to be advocating a 'common' is unusual for me.
Tom Petch
Just a warning, refactoring to remove the "replication" works best as Paul
Jeong has done it. It is careful and precise work reviewed by a few
experts. The working group reviews for high level content. Paul Jeong's
presentation at IETF 113 gave that type of review. I wish we would have
had a longer time period, but hybrid meetings shorten "off-line meetings".
WGs focus on protocol content (routing or security WG) struggle to maintain
moment cycling around refactoring. Combing the refactoring work with
additional work helps keep a working group functional.
Any advice?
Sue
Opinion: The IETF needs to strong cross-area management as we head into 5G
work. Security in all areas is key for 5G needs.
-----Original Message-----
From: t petch [mailto:[email protected]]
Sent: Friday, March 25, 2022 5:05 AM
To: Mr. Jaehoon Paul Jeong; [email protected]
Cc: Roman Danyliw; Panwei (William); Henk Birkholz; tom petch; yangpenglin;
Susan Hares; DIEGO LOPEZ GARCIA
Subject: Re: [I2nsf] Request for Comments, Interest and Support in I2NSF
Re-Chartering
On 24/03/2022 07:38, Mr. Jaehoon Paul Jeong wrote:
Hi I2NSF WG,
As you know, our I2NSF WG will discuss the I2NSF Re-Chartering
at IETF-113 I2NSF WG Session today.
I attach the text of the re-chartering as pdf and txt files.
Those that have worked on the current five I2NSF I-D will know that they
do not subscribe to the basic tenet of 'reference not replicate' and in
doing so have created many issues of lack of coherence (some of which
have been resolved, some of which may never be resolved) and have
created much additional work. In a sense, the current work is built on
foundations of sand, which may or may not support ongoing work.
What is needed, and for me it is the overwhelming priority, before any
new models are crafted, is a 'common' I-D to reduce or eliminate this
replication even if it cannot be applied immediately to those five I-D.
The current charter hints at the need for this in its bullets and in
its list of deliverables. The terminology draft might have done this
but has gone in a slightly different direction. Common YANG capability
statements are an obvious example but even a common base of plain text
would make the work simpler, less error-prone.
Tom Petch
Our five core I2NSF YANG data model drafts are almost completed.
----------------------------------------------------------------------------
--------
1. Capability YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model
-27
2. NSF-Facing Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-
dm-22
3. Monitoring Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-m
odel-16
4. Consumer-Facing Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-inter
face-dm-17
5. Registration Interface YANG Data Model
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interfac
e-dm-15
----------------------------------------------------------------------------
--------
The three of them (i.e., 1, 2, and 3) got the feedback of the IESG and
the revisions have been sent to the IESG reviewers.
The remaining two (i.e., 4, 5) are well-synchronized with the others.
I will present the updates of them today's I2NSF WG.
I attach the slides for them for your easy checking.
Our AD Roman has concerns about the low energy of our I2NSF WG for the new
work items in the I2NSF Re-chartering.
Could you speak up your voice about your comments, interest, and support
of
our I2NSF Re-Chartering?
See you online at IETF-113 I2NSF WG Session today.
Thanks.
Best Regards,
Paul
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
.
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
