Re: BGP autodiscovery design team

--===============6681901261683766113==
Content-Type: multipart/alternative; boundary="0000000000005090a90598f535d1"

--0000000000005090a90598f535d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES <[email protected]> wrote:

> *I agree with Roberts=E2=80=99 point. Prior to crafting or selecting a dr=
aft as
> the basis for a proposal the design team should clearly articulate the
> scope, use cases and requirements that need to be addressed. IMO stating
> that in an informational RFC is a good way to ensure that all stakeholder=
s
> are in agreement as to what the eventual specification/draft addresses, a=
nd
> as important does not address. When creating EVPN we first crafted an
> informational RFC https://tools.ietf.org/html/rfc7209
> <https://tools.ietf.org/html/rfc7209> that specified Active/Active
> Multi-homing, flooding and multicast optimization etc=E2=80=A6 which form=
ed the
> basis for the RFC 7432. This focused the design team on realizing the
> requirements articulated there.*
>

I think the above is good feedback.

Also, it appears the entire working groep is interested to be part of the
design team. Perhaps the design team=E2=80=99s mailing list should be idr@i=
etf.org?
:-)

Kind regards,

Job

--0000000000005090a90598f535d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES &lt;<a href=3D"mailto:ju173=
[email protected]">[email protected]</a>&gt; wrote:<br></div><div><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"m_7033395151118210597WordSection1">
<p class=3D"MsoNormal"><b><span style=3D"font-size:12.0pt;color:#7030a0">I =
agree with Roberts=E2=80=99 point. Prior to crafting or selecting a draft a=
s the basis for a proposal the design team should clearly articulate the sc=
ope, use cases and requirements that need to
 be addressed. IMO stating that in an informational RFC is a good way to en=
sure that all stakeholders are in agreement as to what the eventual specifi=
cation/draft addresses, and as important does not address. When creating EV=
PN we first crafted an informational
 RFC <a href=3D"https://tools.ietf.org/html/rfc7209" target=3D"_blank">http=
s://tools.ietf.org/html/rfc7209</a> that specified Active/Active Multi-homi=
ng, flooding and multicast optimization etc=E2=80=A6 which formed the basis=
 for the RFC 7432. This focused the design team on realizing
 the requirements articulated there.</span></b></p></div></div></blockquote=
><div dir=3D"auto"><br></div><div dir=3D"auto">I think the above is good fe=
edback.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, it appears=
 the entire working groep is interested to be part of the design team. Perh=
aps the design team=E2=80=99s mailing list should be <a href=3D"mailto:idr@=
ietf.org">[email protected]</a>? :-)</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Kind regards,</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Job</div></div></div>

--0000000000005090a90598f535d1--


--===============6681901261683766113==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr

--===============6681901261683766113==--