Subject: [I2nsf] Zaheduzzaman Sarker's Discuss on draft-ietf-i2nsf-capability-data-model-25: (with DISCUSS and COMMENT)

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 03:13:50 -0800

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-i2nsf-capability-data-model-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this data-model. It seems useful specification to have.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I would like to discuss the
followings

  1. With RFC9000 and live traffic in the Internet it feels a bit odd to not
  mention QUIC as transport protocol. I initially thought it might have been
  part of UDP identity and capabilities. However, could not reason with that
  take as there will QUIC and UDP traffic mix and treating them same will not
  be the correct approach. I also think I am not the first one to notice that
  QUIC is missing and it might have been excluded with proper thoughts. In that
  case I would like to know more about it.

  2. With live 5G networks, a similar observation as above for
  "voip-volte-phone" identity and "voip-volte-filtering" identity. The term
  'volte' makes this identity very much specific to a particular cellular
  network generation, LTE (4G). Even though the same network infrastructure for
  'volte' can be and will be used to enable 5G voice, I didn't understood the
  reasoning behind a 'volte' specific identity and filtering. Was this
  intentional and the idea is to extend the data-model for all the cellular
  network generations when needed? I think the need is already now. Alternative
  would be to have the identity and filtering independent of cellular network
  generation. Has this been considered?

  3. I am not sure the high level of HTTPS identity and capabilities definition
  is good enough? We have multiple generations of HTTP and underlying transport
  protocol for those generations are not same, neither allows same kind of
  operations to be performed. for example, HTTP2 over TCP/TLS , with might
  allow termination of TLS context by the intermediaries, will not be true for
  HTTP3 over QUIC. I understand that the actual policy and conflict resolution
  is out of scope of this specification. However, I could not resist myself to
  think about a case where a policy rule may allow HTTPS traffic but blocks
  general UDP traffic. This would mean that HTTPS traffic with QUIC as
  transport protocol will be blocked, which might not be the intention at all.
  (Note that if QUIC traffic is blocked the clients will fall back to TCP/TSL
  as transport protocol(s).) I believe to be more functional the general HTTPs
  capabilities and rule need to be more granular and specific to HTTP
  generations. What is the thinking here?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I had noticed couple of reference issues, those were also picked up by Martin
and Francesca. I see the authors have already take care of those. Thanks for
being prompt.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 11 Feb 2022 01:47:03 +0900

Hi Zaheduzzaman,
Here is the revised draft reflecting your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-26

I attach the revision letter to explain how the revision
is done by Patrick and me for your comments.

[Review by Zaheduzzaman Sarker and Response by Authors] starts from page 35
in the revision letter.

Thanks for your valuable comments and help.

Best Regards,
Paul

On Thu, Feb 3, 2022 at 8:14 PM Zaheduzzaman Sarker via Datatracker <
[email-masked]> wrote:

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

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 18 Feb 2022 10:34:28 +0000

Hi Paul,

Thanks for addressing my comments. I am happy with most of the resolutions in the revision letter.

Regarding inclusion of QUIC, I understand at this stage it will take efforts and time to include QUIC in the I2NFS documents. However, it is fact that QUIC traffic is in the networks; QUIC and UDP traffic should not be teated as the same. Hence, I would suggest to add a note about the reason for intentional exclusion and potential future inclusion of QUIC in the current I2NFS documents. This would act as a warning for the implementors as well.

BR
Zahed 

> On 10 Feb 2022, at 17:47, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Hi Zaheduzzaman,
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-26 <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-26>
> 
> [Review by Zaheduzzaman Sarker and Response by Authors] starts from page 35 in the revision letter.
> 
> On Thu, Feb 3, 2022 at 8:14 PM Zaheduzzaman Sarker via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/>
> 
> 
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>, a
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> <Revision-Letter-for-I2NSF-Capability-Data-Model-26-2022-02-10.pdf>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 18 Feb 2022 21:57:54 +0900

Hi Zahed,
I will follow your guidelines about QUIC.

Thanks for your comments and support.

Best Regards,
Paul

2022년 2월 18일 (금) 오후 7:34, Zaheduzzaman Sarker <
[email-masked]>님이 작성:

> Regarding inclusion of QUIC, I understand at this stage it will take
> efforts and time to include QUIC in the I2NFS documents. However, it is
> fact that QUIC traffic is in the networks; QUIC and UDP traffic should not
> be teated as the same. Hence, I would suggest to add a note about the
> reason for intentional exclusion and potential future inclusion of QUIC in
> the current I2NFS documents. This would act as a warning for the
> implementors as well.
>
> BR
> Zahed
>
> --
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>