Dear Alvaro, Thank you for your comments.
On Thu, Nov 21, 2019 at 07:42:05PM -0800, Alvaro Retana wrote: > > Finally, where appropriate, the GROW documents the operational > > aspects of measurement, monitoring, policy, security, and VPN > > infrastructures, and safe default behavior of implementations. > > It is important to highlight somewhere that protocol changes (to, for > example, meet that "safe default behavior") are to be developed in the > WG chartered with maintaining the specific protocol. idr for BGP, in > close coordination with grow, of course. > > idr is also in the process of discussing an update to their charter. > An important highlight in the text there will be precisely that. I agree that IDR governs BGP and is expected to be its overall architect, gatekeeper, primary caretaker. But IDR is not the *only* group to influence aspects of the BGP Protocol. > > GROW will also advise various working groups, specifically the IDR > > and SIDROPS working groups, with respect to whether it is addressing > > the relevant operational and routing security needs of networks, and > > where appropriate, suggest course corrections or intervene. Finally, > > operational requirements developed in GROW can also be used by any > > new working group charged with standardizing a next generation > > inter-domain routing protocol. > > I don't think I understand what you mean by "suggest course > corrections or intervene". The current Charter ends this sentence > with "suggest course corrections", what is the meaning/intent of > "intervene"? How does that look as a WG? As an example RFC 8212 comes to mind. I would like to suggest that we have a phone call with the IDR and GROW chairs, you, and Warren, to have a dialogue to explore what what is on people's minds and how we want to express that in charters. > > Jul 2021 - "Devise a BGP Community Description System" to IESG > > Maybe this is explained somewhere else (??)...what is that? Is it > simply best practices/recommendations on how to structure the contents > of communities, or something else? Over time it has come up a couple of times that it would be beneficial to have a framework that allows operators to inform each other what the semantics are of locally significant BGP communities (of any flavor). This morning I interjected the idea https://mailarchive.ietf.org/arch/msg/grow/8k5gaWqU1fB4ItlRASv5Q7mUiUM, no further documentation exists other than in our memories. In other words: a way to programmatically tell each other that "Community 1" means X and "Community 2" means Y in NTT's network, and in AT&T's network it is the reverse. I envision we can devise a mechanism to map semantics to integers. This is not work about 'on the wire'. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
