Re: [Idr] some thoughts on draft-ietf-idr-bgp-model-09.txt

[tom petch <[e-mail]>]

From: Idr <[e-mail]> on behalf of tom petch <[e-mail]>
Sent: 06 August 2020 10:17

From: Susan Hares <[e-mail]>
Sent: 05 August 2020 12:17

Tom:

Thank you for the comments.    The history of the BGP model has a long
history and it a large project.    Your feeling is probably correct.. but
we'll try to address these issues.   The sub-modules were the wisdom at the
start of this work.

As to the missing references, we'll ask John to hold the start of WG LC
until we address your comments.  This model is also out at the Yang Doctors
to review prior to start of WG LC.

<tp>

Sue, John

I have seen Acee's review of this I-D and agree with him, especially about submodules, so I shall put this on hold until I see a resolution to the issues he raises (regardless of whether or not a revised I-D appears which addresses the issues that I raised).

Tom Petch

Sue, John

I floated the question of the benefits of submodules on the NETMOD list to which everyone, so far, except Mahesh, said there are none and should be removed from YANG 2.  This I-D would be easier for me to review without submodules; the fact that the submodule names must be registered with IANA and are not in this I-D suggests to me an incomplete grasp of submodules.  I will be interested to see what the YANG doctor says in this regard.

Apart from submodules, the other big showstopper to my comprehension is prefix, with inconsistent use of prefix and the wrong prefix being used for existing, published modules.  YANG allows you to change the prefix - 'YANG Guidelines ' does not.  Along with the use of br.. prefix, there are probably over 100 places in this I-D where the prefix must be changed to conform to the rules.  Look for example at routing policy where rpol: is (mis)used instead of rt-pol:

This could be an interesting Last Call.

Sue, I hope you can get away from it all for your vacation.

Tom Petch


I am on vacation this week and most of next week. I saw your emails and I
wanted to make sure you got a response.   I'll dig in once I'm back full
time.

Thanks for pointing things out.

Sue


-----Original Message-----
From: tom petch [mailto:[e-mail]]
Sent: Monday, August 3, 2020 5:31 AM
To: Susan Hares; [e-mail]
Subject: some thoughts on draft-ietf-idr-bgp-model-09.txt

This I-d needs a significant amount of work; for me it has a slight flavour
of a large project that has been subcontracted out and now needs (more)
systems integration.

I note that it uses submodules extensively, not something I can recall
seeing in an IETF module.

The YANG references 32 documents - good - of which 11 are missing from the
I-D references - not good.

scharf-tcpm-yang-tcp is an import and so MUST be a Normative (think about
it; TCPM just published an I-D that started life 10 years ago, while NETCONF
started work on modelling TCP many years ago and have yet to reach WGLC).

Do submodule names need registering?
"   Names of submodules published in RFC streams [RFC4844] MUST be
   assigned by IANA; see Section 14 in [RFC6020]."
That's another 12 entries needed in IANA.

There are 11 include by date which means that more recent versions will not
be picked up and that there are 11 places where the RFC editor must insert
the right date, probably something they have not done before.

YANG allows freedom over the choice of prefix but exercising that freedom is
not always helpful.  'bgp' is the obvious choice for the main module.
Elsewhere, with main and ancillary modules, a common pattern is for the main
to be e.g. axy and the ancillary axy...

Two letter prefix are best reserved for widely imported modules - interfaces
comes to mind. 'bt' will be a familiar abbreviation to many in the IETF
while 'bp' will have a resonance for those living near the Gulf of Mexico.

A table of imports and prefix used aids comprehension.

derived-from-or-self suggests that you expect other protocol to derive an
identity from bgp; what do you have in  mind?

action to clear neighbours can be invoked by anyone; perhaps a security
exposure.  'These ... operations ...' seems incomplete.

Overall, I wonder at the use of submodules.  Greater size, greater
complexity, more difficult to review, probably more mistakes; what benefit
offsets this?

From: Idr <[e-mail]> on behalf of Susan Hares <[e-mail]>
Sent: 31 July 2020 17:42
To: [e-mail]
Subject: Re: [Idr] IPR call prior to WG LC for
draft-ietf-idr-bgp-model-09.txt


_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr