Subject: [I2nsf] FW: Zahed's DISCUSS on draft-ietf-i2nsf-capability-data-model

From: "Susan Hares" <[email-masked]>
Date: Mon, 21 Mar 2022 06:02:00 -0400

Roman: 

This is an example of the hurdles placed in front of any Yang model.  

During the original creation gathering of information for the yang model, quic was not even a protocol. 

Cheers, 

Sue 

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]] 
Sent: Monday, March 21, 2022 5:58 AM
To: Roman Danyliw
Cc: [email-masked]; [email-masked]
Subject: Re: Zahed's DISCUSS on draft-ietf-i2nsf-capability-data-model

Hi Roman,

Patrick and I will think of how to support QUIC in the I2NSF Capability Data Model

even though such a support of QUIC seems not to be straightforward.

Thanks.

Paul

On Mon, Mar 21, 2022 at 6:42 PM Roman Danyliw <[email-masked]> wrote:

Hi!

I've been working on getting the ADs to clear their DISCUSSes on draft-ietf-i2nsf-capability-data-model (and not worried about COMMENTs right now).  In chatting with Zahed:

** Per DISCUSS#1, he still wants to see the QUIC language her noted (per https://mailarchive.ietf.org/arch/msg/i2nsf/LdSfbPOx4GVqL0fPP6I1rpuMANg/).  That isn't in -26.

** He has confirmed that his DISCUSS#2 (on VoLTE) is resolved in -26.  Thanks.

** Per DISCUSS#3, he would clear his DISCUSS on disclaimer language similar to QUIC on HTTP/3.

Thanks,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 21 Mar 2022 16:41:36 +0000

Hi!

(Aside: There is some confusing threading because this message is on the public i2nsf@ mailing list, but it originated from a private offlist discussion where additional discussion is occurring).

I would benefit from some background on how Zahed’s (https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ballot/#draft-ietf-i2nsf-capability-data-model_zaheduzzaman-sarker) inquiry about QUIC support translates into generic hurdle placed in front of any Yang modules.  My understanding of this DISCUSS point is that it is inquiring why a security data model that allows filtering/selection of network traffic (in Yang or otherwise) doesn’t include a representation for a widely used protocol (QUIC).  A related issue is that of timing – the data model work started before the protocol in question existed (QUIC).  This feedback (of QUIC missing) would seem to have been equally fair for a MIB, JSON, text file-based data model facing the same timing challenge.

Roman

From: Susan Hares <[email-masked]>
Sent: Monday, March 21, 2022 6:02 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]
Subject: FW: Zahed's DISCUSS on draft-ietf-i2nsf-capability-data-model

Roman:

Cheers,

Sue

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
Sent: Monday, March 21, 2022 5:58 AM
To: Roman Danyliw
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Zahed's DISCUSS on draft-ietf-i2nsf-capability-data-model

Hi Roman,

Thanks.

Paul

On Mon, Mar 21, 2022 at 6:42 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

Thanks,
Roman

---

From: t petch <[email-masked]>
Date: Mon, 21 Mar 2022 17:30:13 +0000

> I would benefit from some background on how Zahed’s (https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ballot/#draft-ietf-i2nsf-capability-data-model_zaheduzzaman-sarker) inqu…

I know no more than I see on the I2NSF and Last Call lists but saw 
Zahed's comment as a fair one for an AD to make, similar in kind to 
those about the lack of coverage of POP3S or IMAPS or HTTP/2 support, 
but with a simple resolution of adding a statement that QUIC was out of 
scope at this time, a subject for future study.  I see a lot of energy 
going into QUIC and so think it worth acknowledging its existence (which 
I would not say of some other protocols that may have been around for 
longer).

Tom Petch

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>