Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected]
On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper <[email protected]> wrote: > > On Mar 6, 2018, at 11:11 PM, Donald Eastlake <[email protected]> wrote: > > Hi Alissa, > > On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <[email protected]> wrote: > > Alissa Cooper has entered the following ballot position for > draft-ietf-trill-vendor-channel-00: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm having trouble understanding what function this specification serves > given > that the RBridge Channel Protocol registry has a range reserved already for > private use and that the document doesn't specify any requirements around > vendor-specific protocol semantics. So any implementation of this that needs > to > interoperate with another implementation will need to do so according to > some > specification generated by the vendor, and that specification can select a > code > point from the private use range. What does allocating a single code point > for > all such vendor-specific protocols achieve, aside from specifying a > structured > way of conveying the OUI/CID (which seems superfluous anyway for multiple > implementations from a single vendor interoperating with each other)? > > > What if two TRILL campuses using the same private code point for > incompatible purposes are accidentally interconnected? > > What if someone wants to use TRILL switches from two different vendors > each of which uses the same private code point for incompatible > purposes? Say one vendor makes highly flexible/desirable edge TRILL > switches while the other make particularly cost effective core TRILL > switches or particularly nifty Level 1 / Level 2 border TRILL > switches, or whatever. > > "private" code points seem pretty flakey compared with the more robust > mechanism in this draft. > > Maybe this document should also depredate the use of private code points. > > > Right, both of those examples make it sound like the purpose of having this > document specify a code point is because the existing private use range is > problematic. Your first example seems to directly contradict the guidance in > RFC 7178 about the use of the private range, so if that is a real concern > and it outweighs the utility of having the private range for private network > use, then it seems like deprecation of the private range might make sense. > > The second example I see is the compelling use case for this. I will clear. > > Thanks, > Alissa > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with the Gen-ART reviewer that the text in the Acknowledgements > section > is not appropriate. See RFC 7322. > > > OK. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
