Med, Yes. That does make sense. This looks good.
-andy On 7/7/26 6:27 AM, [email protected] wrote: > 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]
