[As WG Chair] Hi LSR-WG,
As my co-chair has joined the draft as a co-author making the call on whether we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now falls to me alone. I've reread the numerous emails on this adoption call and I see some support, and a few objections, and most of the objections are not that there is no problem to solve here, but they think this draft isn't the right way to do it and a revision of RFC5316 could be done instead. "A bird in the hand is worth two in the bush" While it might be nice that there is another way to accomplish things by re-using an existing TLV, that work has not been done, whereas we have a written draft in front of us -- that has now been beaten up and reviewed a good deal -- that does seem to provide a solution to an actual problem. So I'd like to give the WG a final chance to comment here, is there a strongly compelling reason to reject the work that is done here. Examples of "strongly compelling" would be something like "This will break the (IS-IS) decision process" or "this will badly affect scaling" or "this will significantly complicate a protocol implementation", but not "this can be done differently" as the latter is work not done (i.e., it's two birds "in the bush") I am *not* looking to rehash the entire discussion we've already had so please restrict your replies to the above question only. Thanks, Chris. [As WG Chair] _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
