Re: [Idr] WG LC on draft-ietf-idr-wide-bgp-communities-06.txt (2/4/2022 to 2/18/2022)

[Robert Raszuk <[e-mail]>]

Hi Job,

The URL Keyur sent is correct and points to correct document:

https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/

The implementation wiki indeed has some broken links to draft-idr-rpd ...
maybe copy and paste error ? Not sure. Maybe someone needs to do some
cleanup on it ?

Many thx,
Robert



On Mon, Feb 7, 2022 at 4:11 PM Job Snijders <[e-mail]> wrote:

> Hi Robert,
>
> On Mon, Feb 07, 2022 at 03:52:45PM +0100, Robert Raszuk wrote:
> > >   * support for T/C/R bits (section 3.1)
> >
> > Where do you see R bit in the latest version as per subject line ?
> >
> > >       * no targets
> > >       * atoms (both 4.4.1 + 4.4.2)
> >
> > Implementations can clarify that,.
> >
> > >      * RouterAttr_
> >
> > Can you point to the text
>
> If the text at this URL is outdated, WGLC is going to be really hard
> because how can the working group assess whether the document has been
> adequately implemented and tested for interopability, if the report
> contains outdated or incorrect information?
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-wide-bgp-communities
>
> Please revise the above Trac wiki as needed.
>
> > In general I think if we start cutting any spec into N different
> documents
> > each progressing only when there are two documented implementations of
> its
> > optional parameters or fields it is going to be a huge mess both
> > implementation wise as well as
>
> I disagree.
>
> > What I think matters is if not implementing optional capabilities in any
> > negative way affects the core purpose of the spec. If yes I agree such
> > elements should be removed before publication. But if not I see no harm
> to
> > leave them in the WG document/RFC.
>
> So we agree on removing substantial parts of the internet-draft?
>
> Kind regards,
>
> Job
>