Re: [GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 15/Sep/2022)

[Camilo Cardona <[e-mail]>]

Hello Tom,

First of all, thanks a lot for your thoughtful review of the model. Some answers  next:

> On 26 Aug 2022, at 11:23, tom petch <[e-mail]> wrote:
> 
> From: GROW <[e-mail] <mailto:[e-mail]>> on behalf of Jeffrey Haas <[e-mail] <mailto:[e-mail]>>
> Sent: 25 August 2022 15:25
> 
> I support adoption.
> 
> The draft's YANG is already in better shape than some stuff that's been in other working groups for a few years. :-)
> 
> <tp>
> Yes but with room for improvement :-(  Nothing to stop adoption  but ..
> 
> References seem to lack 1191, 8529, 8671, 9069, tcp-client-server, tcpm-yang; references tell me whether or not I should expect to understand an I-D so they are my second port of call in a review.

<JCC> We’ll take a look at those

> 
> one identifier has an underscore - legal but generally a bad idea, easy to misread - hyphen-minus is better. 

<JCC> I couldn’t find the identifier in the model (the text does reference “all_peers” erroneously, we’llf fix that one. We’ll use hyphen-minus  in the identities.
> 
> ip address uses the format with a zone; is this intended?

<JCC> It was not indented. I guess that having the zone ip makes sense for corner cases, but I have no experience with ip zones. Does anybody have an educated answer?

> 
> XXXX by convention means  this I-D  - here it is used to mean a number of I-D none of which is this one.  Suggest  AAAA, BBBB, CCCC etc
> 
> BCP14 boiler plate is included but all appearances of 'must' and 'should'
> are lower case AFAICT.
> 
> revision date is OOD

<JCC> ack to the 3 previous points 
> 
> identity identifiers get a bit cumbersome - e.g. bmp-ni-types-all-ni-idty which is about sending updates which I would not have guessed from the identifier:-)

<JCC>  Searching for that discussion in opsawg you mentioned, I realised that the final OPSAWG draft removed the idty from the identities. Let us iterate on this. Naming is always tricky, specially with this concepts that are not simple, so we might need a couple of attempts. 
> 
> 'waits for the connection to start the connection'  ?
> 
> port 27716 is one that can be assigned - better to use one from the Private Range

<JCC> Ack the the previous two points
> 
> More generally, the I-D is heavily dependent on the BGP one, which makes sense, but I am conscious that a previous effort to model BGP, albeit some time ago, never made it to RFC.

<JCC> The BGP model is still in active development, as far as I know. And yes, since we will rely on that model, we hope that one continues to become a RFC in not so many years...
> 
> Tom Petch
> 
> 
> -- Jeff
> 
> 
>> On Aug 25, 2022, at 10:20 AM, Job Snijders <job=[e-mail]> wrote:
>> 
>> Hi GROW,
>> 
>> At the IETF 114 GROW session Paolo asked whether this working group
>> could consider adoption for draft-cptb-grow-bmp-yang.
>> 
>> This message is a request to the group for feedback on whether this
>> internet-draft should be adopted.
>> 
>> Title: BMP YANG Module
>> Abstract:
>>  This document proposes a YANG module for BMP (BGP Monitoring
>>  Protocol) configuration and monitoring. A complementary RPC triggers
>>  a refresh of the session of a BMP station.
>> 
>> The Internet-Draft can be found here: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/
>> 
>> Please share with the mailing list if you are think this work should be
>> adopted by GROW, willing to review and/or otherwise contribute to this
>> draft!
>> 
>> WG Adoption call ends September 15th, 2022.
>> 
>> Kind regards,
>> 
>> Job
>> 
>> _______________________________________________
>> GROW mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/grow
> 
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
> 
> _______________________________________________
> GROW mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>