Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
Tony Przygienda <[email protected]> Thu, 15 Feb 2018 08:53:10 -0800
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CA+wi2hOw5oO8hgAUa=xu5m707i9=GHgNQ5hTF70iH=2OPdQg3w__3641.01370000771$1518713547$gmane$org@mail.gmail.com> |
--===============6408210383652112707== Content-Type: multipart/alternative; boundary="f40304394f787b05eb0565431215" --f40304394f787b05eb0565431215 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[email protected]> wrote: > For the record, there is no SR Registry. There is only an IGP Algo Type > Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 > section 8.5 > So is that a good idea, having multiple drafts in flight with fields expecting to have magic couplings to each other while leaving e'thing "unspecified" to "publish RFCs" while we "decide things later"? > > > a) No IGP or SR working group has any charter to mandate any of the >> BIER technology so as well-meant the suggestion seems to be, it has no >> standing in IETF working procedures as far as I can see unless according >> charters are extended by ADs. Unless I'm missing something here. >> > > If a WG points to a registry of any kind, a draft is all that is needed to > justify an new entry in the registry. > Forthcoming today as I said ... For all practical purposes having a _single value_ in a field that can accommodate more in the future can mandate a registry and we already have 0 BTW. And it looks we will/may have more so I can't follow the apparent logic here that we don't need a registry because "we don't have values today" but so we publish an RFC without registry which implies we don't need a registry later in case we have values? > > >> b) More as a question: Can we even publish an RFC now >> (experimental) pointing to an SR draft as normative? And if, how do we move >> it to intended standards track unless SR draft is a standards RFC? >> > > Nobody is asking to reference it now. The current issue on the table to to > leave it undefined with only default value, so let's stick with the current > issue. > I leave it to the judgement of IESG and AD then whether they progress things to RFCs (intended for standards track) with undefined fields for which the "interpretations" will come later. The issue was here 6 months ago and was muscled, the issue is obviously now on an open consensus building list. It will not magically go away. I still see a registry as a long-time proven way to anchor multiple ideas coming into a technology safely and fail to understand how we have things that will be "aligned" but are not "depending to each other" while "documentations" are not "registries" from the continuation of your email, Greg ... And I lived through enough codepoint squatting wars and WG charters stepping onto each others feet to not having the desire to have one more on my hands, hence I welcome the thread ... --- tony --f40304394f787b05eb0565431215 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <span dir=3D"ltr"><<a= href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= ;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">For the = record, there is no SR Registry. There is only an IGP Algo Type Registry as= defined in draft-ietf-ospr-segment-<wbr>routing-extensions-24 section 8.5<= /div></blockquote><div><br></div><div>So is that a good idea, having multip= le drafts in flight with fields expecting to have magic couplings to each o= ther while leaving e'thing "unspecified" to "publish RFC= s" while we "decide things later"? <br></div><div>=C2=A0</di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><br><= div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"><div dir=3D"ltr"><div>a)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 No IGP or SR working group has any charter to mandate any of t= he BIER technology so as well-meant the suggestion seems to be, it has no s= tanding in IETF working procedures as far as I can see unless according cha= rters are extended by ADs. Unless I'm missing something here.</div></di= v></blockquote><div><br></div></span><div>If a WG points to a registry of a= ny kind, a draft is all that is needed to justify an new entry in the regis= try.=C2=A0</div></div></div></div></div></blockquote><div><br></div><div>Fo= rthcoming today as I said ... For all practical purposes having a _single v= alue_ in a field that can accommodate more in the future can mandate a regi= stry and we already have 0 BTW. And it looks we will/may have more so I can= 't follow the apparent logic here that we don't need a registry bec= ause "we don't have values today" but so we publish an RFC wi= thout registry which implies we don't need a registry later in case we = have values?<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa= n class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= r"><div>b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 More as a question: Can we e= ven publish an RFC now (experimental) pointing to an SR draft as normative?= And if, how do we move it to intended standards track unless SR draft is a= standards RFC? <br></div></div></blockquote><div><br></div></span><div>Nob= ody is asking to reference it now. The current issue on the table to to lea= ve it undefined with only default value, so let's stick with the curren= t issue.</div></div></div></div></div></blockquote><div><br></div><div>I le= ave it to the judgement of IESG and AD then whether they progress things to= RFCs (intended for standards track) with undefined fields for which the &q= uot;interpretations" will come later. The issue was here 6 months ago = and was muscled, the issue is obviously now on an open consensus building l= ist. It will not magically go away. I still see a registry as a long-time p= roven way to anchor multiple ideas coming into a technology safely and fail= to understand how we have things that will be "aligned" but are = not "depending to each other" while "documentations" ar= e not "registries" from the continuation of your email, Greg ...= =C2=A0 And I lived through enough codepoint squatting wars and WG charters = stepping onto each others feet to not having the desire to have one more on= my hands, hence I welcome the thread ... <br><br></div><div>--- tony <br><= /div><div>=C2=A0</div></div><br></div></div> --f40304394f787b05eb0565431215-- --===============6408210383652112707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg --===============6408210383652112707==--