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. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
