On Wed, Nov 11, 2020 at 10:28 AM Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote: > > > > On 11 Nov 2020, at 16:07, Toerless Eckert <t...@cs.fau.de> wrote: > > On Wed, Nov 11, 2020 at 10:34:25AM +0100, Eliot Lear wrote: > > Hang on a moment. > > The PCAP community has been looking for a home to evolve the work. > > > We can decide on whether to start with informational or STD > but the reason to lean toward the latter is that this is a broadly used > standard > that is looking for a home to evolve. > > > So, how is this base specification not a pre-ordained protocol developed > outside the IETF that can not be significantly shaped through the work > of the WG if/when it sees the need to do so ? > > > It’s a starting point like any other individual draft. The only difference > here is that those who take part in the consensus process are more likely to > weight the fact that there is a lot of running code. > > > 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> 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 > OPSAWG@ietf.org > 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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
