Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

[Bob Hinden <[e-mail]>]

Hi,

> On Sep 17, 2019, at 6:13 PM, Mark Smith <[e-mail]> wrote:
> 
> 
> 
> On Wed, 18 Sep 2019, 06:33 Brian E Carpenter, <[e-mail]> 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