Hi Jiankang/Andy, I think the second point was parked per the reply from Andy.
For the first point: > > ### MUST or must > > > > 389 Batch-oriented processing (combining multiple EPP > commands in a > > 390 single data unit) is not permitted. Each EPP data > unit must > > 391 contain a single EPP message. > > > > Should this be a normative MUST? > > > I think that MUST is fine. I don't see the change made in the latest version, which I think is OK given that Section 4 already has the normative language: CURRENT: Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently. Andy, do you think any further change is needed here? Cheers, Med > -----Message d'origine----- > De : Jiankang Yao <[email protected]> > Envoyé : mercredi 1 juillet 2026 02:05 > À : Andy Newton <[email protected]> > Cc : The IESG <[email protected]>; draft-ietf-regext-epp- > [email protected]; [email protected]; [email protected]; > [email protected]; Gould, James <[email protected]> > Objet : [iesg] Re: [regext] Andy Newton's Discuss on draft-ietf- > regext-epp-quic-10: (with DISCUSS) > > > Hello Andy, > > Thanks a lot. Some comments inline below. > > > > > 2026年7月1日 04:42，Andy Newton via Datatracker > <[email protected]> 写道： > > > > Andy Newton has entered the following ballot position for > > draft-ietf-regext-epp-quic-10: 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.) > > > > > > > > > > ---------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------- > > > > > > > ### MUST or must > > > > 389 Batch-oriented processing (combining multiple EPP > commands in a > > 390 single data unit) is not permitted. Each EPP data > unit must > > 391 contain a single EPP message. > > > > Should this be a normative MUST? > > > I think that MUST is fine. > > > > > ### Server Requirement for Client Fall Back > > > > 407 8.1. Clients Fall Back with Management of Multiple > Transport > > > > 409 If the establishment of an EoQ connection fails, > clients MAY attempt > > 410 to fall back to EPP over TCP as specified in > [RFC5734], depending on > > 411 local deployment and security policy. It is up to > clients to > > 412 determine the mix of transports that best meets their > business needs. > > > > While it is up to the client to determine if fall back is > necessary, > > what are the requirements on the server? If a client falls back > to EoT > > but the server doesn't have EoT, isn't that an interoperability > issue? > > I think this can be solved with the following addition: > > > > Servers MUST offer service over TCP (EoT [RFC5374]) for > clients that fall > > back to TCP. > > > > > > Thanks for your kind suggestion. > > > > Section 8.3 has discussed " QUIC Support Announcement and > Discovery”. > > In future, some servers may support EoQ only. > > How about this one: > > If EoQ is not offered, servers MUST offer service over TCP > (EoT [RFC5734]) for clients that fall > back to TCP. > > > Best Regards > Jiankang Yao > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
