> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Brian E
> Carpenter
...
> tom petch wrote:
> > That is why i would like to see if there is a form of adopting this
> > document under
> > specific premises / constraints for acceptable changes
>
>
sage d'origine-
>> De : Carsten Bormann [mailto:c...@tzi.org]
>> Envoyé : jeudi 12 novembre 2020 08:27
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Brian E Carpenter ; opsawg
>>
>> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
>>
>&
Yepp, thats why i was suggesting independent submission in the first place as
the right way to go,
and let OPSAWG just help as mutually beneficial. And then take over with
extensions afterwards.
But then Warren threw rfc8017 into the room, and i have no idea what
the policies where to do that
On 12-Nov-20 23:24, tom petch wrote:
> From: OPSAWG on behalf of Toerless Eckert
>
> Sent: 11 November 2020 20:24
>
> I am mostly worried to figure out if we can try to lock in the admissable
> changes to
> the document as early as possible.
>
> [ I was recently hit with a post-WG IESG
On 2020-11-12, at 06:35, Carsten Bormann wrote:
>
> (But you could still retronym it, PCAP Northern Germany or some such.)
Or explain that it is not an abbreviation at all but just a leet way to get you
to say
Pica-Ping!
Grüße, Carsten
(OK, it’s getting close to Friday here. I’ll
YANG set a pretty solid IETF precedence here. As an individual, I'd +1 a
too late here.
On 12.11.20 00:40, Michael Richardson wrote:
Brian E Carpenter wrote:
> On 12-Nov-20 10:47, Eliot Lear wrote:
>> We didn’t use the ISE for JSON. Why should we use it here?
> I have no
From: OPSAWG on behalf of Toerless Eckert
Sent: 11 November 2020 20:24
I am mostly worried to figure out if we can try to lock in the admissable
changes to
the document as early as possible.
[ I was recently hit with a post-WG IESG concern on a fundamental
aspect of one of my drafts, and
this was handled in other
>> contexts but with similar goals.
>>
>> Cheers,
>> Med
>>
>>> -Message d'origine-
>>> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Brian E
>>> Carpenter
>>> Envoyé : mercredi 11 nove
CADAIR Mohamed TGI/OLN
> Cc : Brian E Carpenter ; opsawg
>
> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
>
> I think IAX2 is a nice example for a protocol that would not have
> been designed that way in the IETF. So independent stream was
> appropriat
e la part de Brian E
>> Carpenter
>> Envoyé : mercredi 11 novembre 2020 21:15
>> À : Toerless Eckert ; Eliot Lear
>> Cc : opsawg
>> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
>>
>
>> It doesn't, as long as the Independ
g-boun...@ietf.org] De la part de Brian E
> Carpenter
> Envoyé : mercredi 11 novembre 2020 21:15
> À : Toerless Eckert ; Eliot Lear
> Cc : opsawg
> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
>
> It doesn't, as long as the Independent S
On 2020-11-11, at 19:13, Toerless Eckert wrote:
>
> Kidding aside: Maybe the relevant discuss for the fdt mailing list would be
> if we should have/select a formal language to describe the arbitrary binary
> TLV format that we may just inherit and can not be replaced by any of the
>
On 2020-11-12, at 00:40, Michael Richardson wrote:
>
>> If there's a PCAPNGng proposal, bring it here by all means.
>
> Actually, one thing the WG could do is to provide a slightly more sensible
> name, as "NG" is always in the future.
Too late.
(But you could still retronym it, PCAP Northern
Toerless Eckert wrote:
> pcap2010
I've heard worse.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
pcap2010
On Wed, Nov 11, 2020 at 06:40:50PM -0500, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > On 12-Nov-20 10:47, Eliot Lear wrote:
> >> We didn???t use the ISE for JSON. Why should we use it here?
>
> > I have no idea what the arguments were for JSON. Carsten
Brian E Carpenter wrote:
> On 12-Nov-20 10:47, Eliot Lear wrote:
>> We didn’t use the ISE for JSON. Why should we use it here?
> I have no idea what the arguments were for JSON. Carsten already stated
> why the Independent Stream is appropriate for PCAPNG: "PCAPNG is a done
Toerless Eckert wrote:
>> Toerless Eckert wrote:
>> > I am mostly worried to figure out if we can try to lock in the
admissable changes to
>> > the document as early as possible.
>>
>> You can change anything you want as long as a 2018-era release of
wireshark
>> and
We have many times had WGs whose goals included "produce RFC to document
have currently works.? The way we make that stick process-wise
historically is to write that into the charter. Since the IESG signs
off on the charter, generally later ADs understand and work with the
agreement.
I guess one line of bringing new stuff not yet implemented into this
first doc as long as it does not violate the Richardson Doctrine (*),
but i too would find it a lot better to first have a document
solely specifying what is implemented and then do extension in followup
work.
Cheerss
On Wed, Nov 11, 2020 at 06:06:11PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > I am mostly worried to figure out if we can try to lock in the
> admissable changes to
> > the document as early as possible.
>
> You can change anything you want as long as a 2018-era
On 12-Nov-20 10:47, Eliot Lear wrote:
> We didn’t use the ISE for JSON. Why should we use it here?
I have no idea what the arguments were for JSON. Carsten already stated why the
Independent Stream is appropriate for PCAPNG: "PCAPNG is a done deal." So
there's nothing non-editorial to discuss.
Toerless Eckert wrote:
> I am mostly worried to figure out if we can try to lock in the admissable
changes to
> the document as early as possible.
You can change anything you want as long as a 2018-era release of wireshark
and tcpdump can read the result.
--
Michael Richardson. o
Yes, would be good to understood which options was choosen why
(re-published doc informational WG vs individual submission)..
In doubt, if i was an author worried about IETF very late in the process to
create incompatibilities
with existing widely deployed protocols, i would probably prefer
Worth documenting in the draft ;-)
On Wed, Nov 11, 2020 at 05:05:45PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> >> On 2020-11-10, at 22:23, Toerless Eckert wrote:
> >> >
> >> > Why is the document not using a formal language to define the
> >> >
Carsten Bormann wrote:
> PCAPNG is a done deal.
Thank you
> We might want to discuss a next generation after that, but I would
> expect that people are still happy after having migrated from PCAP to
> PCAPNG.
One thing that many people *DO* want is to have more easily parsed
Toerless Eckert wrote:
>> On 2020-11-10, at 22:23, Toerless Eckert wrote:
>> >
>> > Why is the document not using a formal language to define the
>> > syntax/semantic of its formatting ? Would CBOR/CDDL not be a
>> > good candidate ? Any other ?
>>
>> Well, changing
We didn’t use the ISE for JSON. Why should we use it here?
Eliot
> On 11 Nov 2020, at 21:15, Brian E Carpenter
> wrote:
>
> On 12-Nov-20 04:07, Toerless Eckert wrote:
>> On Wed, Nov 11, 2020 at 10:34:25AM +0100, Eliot Lear wrote:
>>> Hang on a moment.
>>>
>>> The PCAP community has been
I am mostly worried to figure out if we can try to lock in the admissable
changes to
the document as early as possible.
[ I was recently hit with a post-WG IESG concern on a fundamental
aspect of one of my drafts, and that not only dragged on the document for a
year or
more, it also
On 12-Nov-20 04:07, Toerless Eckert 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
On 2020-11-11, at 19:13, Toerless Eckert wrote:
>
> Agreed. but this is in contradiction to what others here on the thread claimed
> would be in scope of changes toward RFC, such as "anything", so everybody
> seems
> to chime in wih liking pcapng without first trying to have a clear
>
On Wed, Nov 11, 2020 at 06:02:28PM +0100, Carsten Bormann wrote:
> On 2020-11-11, at 17:33, Toerless Eckert wrote:
> >
> > 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 ?
>
> There could be an
On Wed, Nov 11, 2020 at 12:12:34PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > Why is the document not using a formal language to define the
> > syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> > good candidate ? Any other ?
>
> Because pcapng is
Toerless Eckert wrote:
> Why is the document not using a formal language to define the
> syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> good candidate ? Any other ?
Because pcapng is at least 10 years old, and pcap is around ~33 years old.
If we designed it today,
On 2020-11-11, at 17:33, Toerless Eckert wrote:
>
> 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 ?
There could be an agreement to hand over change control, which could then lead
to a standards-track
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.
>
>
> Yup, the IETF has published a number of documents which are
> descriptions of how things
On Wed, Nov 11, 2020 at 03:15:30PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/11/20, 10:09, "OPSAWG on behalf of Toerless Eckert"
> wrote:
>
> >> This is really a win-win opportunity. The PCAP developers need a
> place that helps them formally
> >> state extensions and
On Wed, Nov 11, 2020 at 10:28 AM Eliot Lear
wrote:
>
>
>
> On 11 Nov 2020, at 16:07, Toerless Eckert 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
On Wed, Nov 11, 2020 at 11:01:54AM +0100, Juergen Schoenwaelder wrote:
> Toerless,
>
> I understand the benefits of formal definitions and tools reasonably
> well but assuming that everybody judges the benefits in the same way
> in every context is in my experience wishful thinking. (Look which
>
> On 11 Nov 2020, at 16:07, Toerless Eckert 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
On 11/11/20, 10:09, "OPSAWG on behalf of Toerless Eckert"
wrote:
>> 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
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
>
On 11/11/2020 11.01, Juergen Schoenwaelder wrote:
Standardizing pcapng has a clear value for me and I strongly support
the effort. And I think we should trust that those who worked out the
pcapng format and implemented it did take proper engineering
decisions. It is fine to ask questions like
Toerless,
I understand the benefits of formal definitions and tools reasonably
well but assuming that everybody judges the benefits in the same way
in every context is in my experience wishful thinking. (Look which
problem ASN.1 tried to solve in the 1980s and how many data formats
did come and
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. Moreover, there is a clear
Thanks for explaining. Cc'in ISE to keep me honest:
I don't think this process ("IETF bless this protocol, no, we can't change
anything
significant") is appropriate for an Internet Standards Track RFC. I can not
even see informatinal as appropriate if WG consensus is constrained by
PCAPNG is a done deal.
We might want to discuss a next generation after that, but I would expect that
people are still happy after having migrated from PCAP to PCAPNG.
So this effort was about documenting the protocol and making sure the extension
points are well-documented and well-curated.
I am sorry, but i don't think human parsing of ASCII diagrams to write code
for a protocol is appropriate for new designs anymore unless there are good
reasons. What are the good reasons ?
Is this another case of ready developed code and the ask is "IETF bless it's
spec" ? Do we even know using
On Wed, Nov 11, 2020 at 03:22:18AM +0100, Toerless Eckert wrote:
> On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote:
> > On 2020-11-10, at 22:23, Toerless Eckert wrote:
> > >
> > > Why is the document not using a formal language to define the
> > > syntax/semantic of its
On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote:
> On 2020-11-10, at 22:23, Toerless Eckert wrote:
> >
> > Why is the document not using a formal language to define the
> > syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> > good candidate ? Any other ?
>
> Well,
On 2020-11-10, at 22:23, Toerless Eckert wrote:
>
> Why is the document not using a formal language to define the
> syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> good candidate ? Any other ?
Well, changing the format to be more regular (e.g., CBOR) is not what we want.
Getting
On Mon, Nov 09, 2020 at 08:23:52PM +0100, Eliot Lear wrote:
> This is good work, it???s a format used everywhere. We also need a registry
> for option extensions that IANA could provide. And we have some ideas as to
> how to use that.
A) As heart warming as all those cozy ASCII graphics in
>> I don’t think we’ve ever formally called for adoption of this work.
>> And this isn’t the first time it’s been discussed (last time one
>> criticism was IETF wasn’t about ratifying file formats, but I think
>> that’s debatable). We’ll put out a call after IETF109 and see where
> On 10. Nov 2020, at 17:51, Joe Clarke (jclarke)
> wrote:
>
> I don’t think we’ve ever formally called for adoption of this work. And this
> isn’t the first time it’s been discussed (last time one criticism was IETF
> wasn’t about ratifying file formats, but I think that’s debatable).
I don’t think we’ve ever formally called for adoption of this work. And this
isn’t the first time it’s been discussed (last time one criticism was IETF
wasn’t about ratifying file formats, but I think that’s debatable). We’ll put
out a call after IETF109 and see where the WG is now.
Joe
>
This is good work, it’s a format used everywhere. We also need a registry for
option extensions that IANA could provide. And we have some ideas as to how to
use that.
Eliot
___
OPSAWG mailing list
OPSAWG@ietf.org
55 matches
Mail list logo
