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 protected]> > wrote: > > Hi Zaheduzzaman, > Here is the revised draft reflecting your comments: > 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> > > 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 protected] <mailto:[email protected]>> wrote: > 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/ > <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/ > <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/ > <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] <mailto:[email protected]> > 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
