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

Susan Hares <> Wed, 05 August 2020 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 036713A1138 for <>; Wed, 5 Aug 2020 04:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ddpQZ0lAvB3 for <>; Wed, 5 Aug 2020 04:17:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DFDE3A1057 for <>; Wed, 5 Aug 2020 04:17:12 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'tom petch'" <>, <>
References: <005401d6659d$31ad4c40$9507e4c0$> <>, <007101d66759$938f7150$baae53f0$> <>
In-Reply-To: <>
Date: Wed, 5 Aug 2020 07:17:03 -0400
Message-ID: <017c01d66b19$f25af510$d710df30$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE+1+XUdv18vKGZHbbpBPNUlsIwVQJKrXvjAcmXYWYBh3J3Xaoro+ug
Content-Language: en-us
X-Antivirus: AVG (VPS 200805-2, 08/05/2020), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] some thoughts on draft-ietf-idr-bgp-model-09.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2020 11:17:14 -0000


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.   

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

Thanks for pointing things out. 


-----Original Message-----
From: tom petch [] 
Sent: Monday, August 3, 2020 5:31 AM
To: Susan Hares;
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 <> on behalf of Susan Hares <>
Sent: 31 July 2020 17:42
Subject: Re: [Idr] IPR call prior to WG LC for