Re: [Idr] WG Last Call on draft-ietf-idr-bgp-model-16

[Mahesh Jethanandani <[e-mail]>]

Hi Tom,

Thanks for trying to review the draft, and for providing comments.

> On Apr 19, 2023, at 10:47 AM, tom petch <[e-mail]> wrote:
> 
> From: Idr <[e-mail] <mailto:[e-mail]>> on behalf of Dongjie (Jimmy) <jie.dong=[e-mail] <mailto:jie.dong=[e-mail]>>
> Sent: 11 April 2023 03:17
> Hi WG,
> 
> This begins the Working Group Last Call for "YANG Model for Border Gateway Protocol (BGP-4)", draft-ietf-idr-bgp-model-16. The draft could be found at: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16>.
> 
> <tp>
> This I-D ticks a lot of the boxes that discourages me from going any further; I do not expect to review it in any level of detail.
> 
> Submodules - what are they? much discussed in the early days of YANG but I see them as an idea whose time never came, just risking an increase in misunderstandings about the rules thereof, e.g. scope of names (which I once knew).

There is nothing in RFC 7950 that suggests that submodules should not be used. The language, and all the current validation tools support them. I see no reason to change unless someone can give us concrete reasons with specific examples of why submodules as they are defined do not work.

> 
> Mixing information with different life cycles, IANA modules that are obsolete as soon as they are published 
> with protocol modules which likely will be revised thus creating a difficult, impossible even, situation for the IETF at a future date as to how to update the document.

That is not in the scope of this draft to define. There are drafts and RFCs that have defined both IANA and IETF modules, and unless IESG can come up with a reason why they should not be combined, I do not see a reason to change. 

> 
> multiple identifiers made so brief - two letter prefix  - that I will struggle to remember what they are

> 
> mismatch of prefix within the I-D

That is a point, and we will work on making the prefixes consistent.

> 
> lots of groupings leading to long lists pf groupings with names that I do not find obvous making the detail hard to follow e.g.
>           uses bgp-adj-rib-attr-state;
>           uses bgp-adj-rib-common-attr-refs;
>           uses bgp-common-route-annotations-state;
>           uses bgp-adj-rib-in-post-route-annotations-state;
>           uses bgp-unknown-attr-top;
>           uses rib-ext-route-annotations;
> (is there an attr-bottom to go with the attr-top?)

Most of these names follow well known constructs within BGP protocol. Folks who commonly work the BGP are familiar with these names and understand the construct.

> 
> Normative Reference to an I-D with MISSREF that may or may not progress soon (shades of OSPF YANG which took a few years to resolve)

Again, not something that is within the scope of this draft to solve. Since interoperability is a given, and re-use of existing models and constructs is important, it is a given that drafts will sit in MISSREF state for sometime to come.

> 
> 'reference to the standard MIB TCP connection table.
> Is the BGP MIB a pre-requisite?

Do not understand the comment. Can you expand on it?

> 
> Out-of- date text such as 
>       "WG Web:   <http://tools.ietf.org/wg/idr <http://tools.ietf.org/wg/idr>>

Will fix.

> and
> Simplified BSD License 
> with example dates in 2016

Will fix.

Thanks

> 
> 
> Tom Petch
> Since all the IDR chairs are coauthors of this document, I’m helping with this last call procedure. Please reply to the list with your comments. Considering this is a long document with a big YANG model, the last call will last for 4 weeks and conclude on Sunday, 7 May, 2023.
> 
> 
> 
> The authors are requested to state whether they are aware of applicable IPR related to this draft. Similarly, if others in the Working Group are aware of applicable IPR, please also disclose them.
> 
> 
> People are encouraged to indicate whether there is implementation of this document. According to the IDR rule, at least two implementations will be required to advance the document.
> 
> 
> 
> 
> 
> Best regards,
> 
> Jie (on behalf of the IDR chairs)
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

Mahesh Jethanandani
[e-mail]