On Wed, Nov 11, 2020 at 11:08:03AM -0500, Warren Kumari wrote:
> > What is the WG allowed to design for this protocol spec ? Wordsmithing
> > and blessing ? Anything else ?
> >
> >
> > Everything else.
>
> <no hats>
> Yup, the IETF has published a number of documents which are
> descriptions of how things work, etc - an extreme example is RFC 8017,
> where the IETF (IIRC) published RSA documents largely unchanged.
>
> This is a well known format, and is well implemented; having it
> properly documented in a standard, easy to reference place seems like
> a good thing to me.
> </no hats>
Correct me if i am wrong, but i don't think that this would include at least in
recent
decades standards track documents, or does it ?
It would just be lovely if the authors would chime in and discuss with the WG
what they would want to see from the WG (publishing house support ?), and
especially
what they do not want to see (change of running code ?).
Asking for adoption without that discussion with the authors is IMHO frivolous.
And i for once think that a new protocol whose prime purpose to go to IETF
is to be easily extensible and adoptable by a wide variety of implementations
across the industry should have an ASCII art encoding specification because
that just leads to a lot of pain points the limit the target goal for
developers and users.
Cheers
Toerless
> W
> P.S: For some reason my mailer seems to have messed up the formatting
> of quoting here...
>
> >
> >
> > Moreover, there is a clear need for IANA here, for tagging information
> > inside the PCAP.
> >
> >
> > That does AFAIK not require IETF WG RFC, and besides, i am not
> > even sure that it even needs an IETF document to create registries @IANA.
> >
> > Worst case one could have an external, not even RFC specification and
> > have the WG a small "bless you pcapng" standards track RFC that does
> > exactly that and asks for creation of the IANA registries.
> >
> > This is really a win-win opportunity. The PCAP developers need a place
> > that helps them formally state extensions and they need a way to not trip
> > over one another on extension numbers. Does that mean we have to take the
> > doc as it is? No. But changes should simply be by consensus, and I doubt
> > you will find a lot of consensus for frivolous changes.
> >
> >
> > Let me know which of my asks you think is frivolous.
> >
> >
> > That will be for the WG to decide. I don???t have a view at the moment.
> >
> > Eliot
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
> ---maf
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
