Hi, Les: Would you like to revisit https://mailarchive.ietf.org/arch/msg/lsr/7DwbQXjBO8qeGsES7In7OavN1mk/ for our previous discussion on this point? If there is no more new contents/inputs, can we stop looping it back again?
I think you should also notice that the bogus information that needs to be flooded within the network, regardless the efforts that the operator must apply these bogus information on all stub links. I am curious you are still sticking to the inappropriate solutions for the operator. Aijun Wang China Telecom > 在 2022年2月19日，11:27，Les Ginsberg (ginsberg) > <[email protected]> 写道： > > Chris - > > I don't agree with everything you state below - but let's put that aside. > You have a tough call to make - no matter what you decide some folks will be > very unhappy - I don't want to make things tougher for you. > > But there is one point that seems highly relevant to me. A compelling case > has been made by multiple folks that RFC 5316 can already do what is > required. All of Aijun's concerns have been addressed in the original email > thread (which is not the same as saying Aijun himself is satisfied on this > point). > I do not see why the WG should take on redundant work. And if you think that > the question as to whether RFC 5316 is sufficient has not yet been answered > to your satisfaction, then I suggest the WG focus on answering that question > - which should be done BEFORE deciding whether to adopt The Stub-Link draft. > That seems to me to be the most appropriate way forward. > > Good luck!! > > Les > > >> -----Original Message----- >> From: Christian Hopps <[email protected]> >> Sent: Friday, February 18, 2022 4:45 PM >> To: Les Ginsberg (ginsberg) <[email protected]> >> Cc: Christian Hopps <[email protected]>; Peter Psenak >> <[email protected]>; [email protected] >> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316 >> >> >> "Les Ginsberg (ginsberg)" <[email protected]> writes: >> >>> Chris - >> >> [... trimmed out the restated points ...] >> >>> I also strongly object to your statement below: >>> >>> " I've asked for cases that this draft would break things, not whether it >>> has >> warts or not." >>> >>> This suggests (intentionally or not) that so long as a draft doesn't break >> anything it is OK to consider it for adoption. I hope we have a higher bar >> than >> that. >> >> No, I really don't think it suggests that if you read my email on this. I >> think it's >> pretty obviously that I'm only talking about this draft, and specifically in >> the >> context of there having already been a great deal of discussion already >> during the adoption call. I am specifically asking that people not rehash >> that >> discussion again is all. >> >> What one can probably safely infer though, by the email, is that it's >> looking to >> the chair like there is rough consensus to adopt the draft. The bar is not as >> high for adoption as it is for WGLC, and so the consensus can be rather >> rough. >> >> Adoption is no guarantee of publication. >> >> In fact, one could imagine someone (perhaps from the objecting group) >> writing an *info* track document that concisely describes how to tie >> together existing IS-IS and OSPF technologies to more cleanly solve the same >> problems this draft is targeting, if that is indeed possible, this >> possibility has >> certainly been suggested in some emails. >> >> One could then imagine this new document is seen by (a rough consensus >> of) the WG as a better, cleaner route to take, and so the WG publishes the >> new document content (either as a newly adopted document, or as large >> modifications to the existing adopted document) instead. >> >> Thanks, >> Chris. >> [as wg chair] > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
