Hi, > On Sep 17, 2019, at 6:13 PM, Mark Smith <[email protected]> wrote: > > > > On Wed, 18 Sep 2019, 06:33 Brian E Carpenter, <[email protected]> > wrote: > Ron, > > You wrote: > > > Isn't this [the Opaque header] also creating an opportunity for IETF WGs to > > bypass IANA, creating their own registry, likely run badly? > > More than that, it's creating an opportunity for operators to bypass IETF > standards as well as IANA. > > Isn't that the essence of this whole discussion? > > They can do it anyway, but defining the code point at least makes it possible > for firewalls to discard such traffic if it escapes. Hence my comment about > draft-ietf-opsec-ipv6-eh-filtering. > > > The word "opaque" means (from Google "meaning opaque"), > > "not able to be seen through; not transparent" > > If a protocol is opaque or not transparent to the IETF then that would mean > somebody else owns it; it's their property rather than the IETFs. > > So somebody else's protocol being referred to by the IETF would fit the > definition of "proprietary": > > "relating to an owner or ownership" > > > So I think Proprietary would be a much more accurate name for this option if > it were to go ahead. > > I'd much rather it didn't so we had a transparent and open IETF protocol. >
I also agree. Since I have started doing a little Wireshark development, I think it’s important that new protocols be possible to parse with network debugging tools like Wireshark. Having a code point that does not have a reference that points to how to parse it makes network debugging difficult if not impossible. I would prefer a code point that have both a descriptive name and points to an open specification for what the protocol looks like that follows. Especially since this work is being done in the IETF. Bob
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
