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 protected]>님이 작성: > 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 > > 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]> 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/ >> 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 >> > <Revision-Letter-for-I2NSF-Capability-Data-Model-26-2022-02-10.pdf> > > > -- =========================== 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 protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
