Re-, Thanks, Steffen.
I think we are almost there, modulo the "paused" item and recording the limitation. > > BTW, what is currently supported by implementations such as > open-brski? > [stf] > [Med] It seems this was one was incomplete. I'm interested still interested, but that's fine if we don't have an answer. Thanks. Cheers, Med > -----Message d'origine----- > De : Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org> > Envoyé : jeudi 10 avril 2025 17:35 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > The IESG <i...@ietf.org> > Cc : draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de > Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-anima-brski- > prm-18: (with DISCUSS and COMMENT) > > > Hi Mohamed, > > Thanks for your comments. As last time, I leave the comments with > reactions and dropped the closed ones for easier reading. > The draft with the updates has been put on the usual place in > github > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fblob%2Fmain%2Fdraft- > ietf-anima-brski- > prm.md&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C94792fe975f > 94fd8972f08dd784543bc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638798961115558475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=0ibhUGU1HfNOMvByzeiLbmnrUu5ruMeye%2B%2FYND > Ev7iE%3D&reserved=0). > > Best regards > Steffen > > > -----Original Message----- > > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > > Sent: Thursday, April 10, 2025 7:11 AM > > To: Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com>; The > IESG > > <i...@ietf.org> > > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > > anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de > > Subject: RE: Mohamed Boucadair's Discuss on > > draft-ietf-anima-brski-prm-18: (with > > > > > > > -------------------------------------------------------- > ---- > > > > > > DISCUSS: > > > > > > -------------------------------------------------------- > ---- > > > > > > # DISCUSS > > > > > > # Compliance with HTTP BCP (RFC9205) > > > > > > > > > > > > CURRENT: > > > > > > If the pledge is unable to create the PVR, it SHOULD > respond with an > > > > > > HTTP error status code to the Registrar-Agent. The > following client > > > > > > error status codes SHOULD be used: > > > > > > > > > > > > The use of normative language is IMO not compliant with > the > > > > > > guidance in RFC9205, about error handling. > > > > > [stf] I created a new issue for this: > > > > > From RFC 9205 I understood that we could use the HTTP > status > > > > > codes in this way. What would you suggest here? > > > > > > > > > > > > > [Med] A simple fix here is to remove the normative language. > > > > Listing the appropriate codes is definitely right, but need > to > > > > redefine the error codes, just be affirmative. For example, > an > > > > entity will return 404 when there is no resources, etc. > > > [stf] Hm, after the discussion in the design team, we are not > quite > > > sure about your concern. Is it the one.-to-one mapping > referenced in > > > section 4.6 of RFC 9205 or the understanding we re- define > status > > > codes? > > > > > > > [Med] I'm afraid that you are redefining those. We don't need > new > > normative HTTP behavior here. I suggest we simply make this > change > > (and similar) > > > > OLD: > > If the pledge is unable to create the PER, it SHOULD respond > with an > > HTTP error status code to the Registrar-Agent. The following > client > > error status codes MAY be used: > > > > * 400 Bad Request: if the pledge detects an error in the > format of > > the request. > > ... > > > > NEW: > > If the pledge is unable to create the PER, it responds with > an > > HTTP error status code to the Registrar-Agent. The following > client > > error status codes can be used: > > > > * 400 Bad Request: if the pledge detects an error in the > format of > > the request. > > .. > [stf] Okay, got it, made the changes as proposed for the different > HTTP status codes > [Med] Thanks. > > > > > > > # Cluster with 8366bis > > > > > > > > > > > > CURRENT: > > > > > > > > > > > > The JSON PVR Data MUST contain the following fields > of the "ietf- > > > > > > voucher-request" YANG module as defined in > > > > > > [I-D.ietf-anima-rfc8366bis]; > > > > > > > > > > > > I think this spec should be clustered with 8366bis. > There are > > > > > > several structure that used in this document and which > depends on what is defined in 8366bis. > > > > > > Changes to the bis will have implications on this one. > > > > > > > > > > > > With that in mind, I tend to suggest holding approval of > this > > > > > > specification till we finalize the bis spec. > > > > > [stf] As indicated by Michael, we already have a cluster > for > > > RFC > > > > > 8366bis and further drafts related to BRSKI variants to > take > > > > > care of mutual influences. I opened an issue > > > > > > > > [Med] ACK. > > > [stf] Also discussed in design team meeting today. It is less > about > > > changes in the draft but more to the processing. The intention > is > > > that all other BRSKI variant documents currently handled will > go > > > into MISSREF, as draft-ietf-jws-voucher waiting for 8366bis. > 8366bis > > > collects considerations from the different documents and is > likely > > > not to lead to addition of new information in the respective > drafts > > > (at least that is the intention). > > > > > > > [Med] I would be more comfortable if I had more stability signs > of > > 8366 ;-) > > > > That's said, I think that I have the discussion I wanted to > have. I > > leave it to Mahesh to decide. > [stf] Okay, agreed > > > > > > > > # Requires TLS1.3 > > > > > > > > > > > > CURRENT: > > > > > > As already stated in [RFC8995], the use of TLS 1.3 > (or newer) is > > > > > > encouraged. TLS 1.2 or newer is REQUIRED on the > Registrar-Agent > > > > > > side. TLS 1.3 (or newer) SHOULD be available on the > registrar, but > > > > > > TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be > available on the > > > > > > MASA, but TLS 1.2 MAY be used. > > > > > > > > > > > > Please update to take into to reflect draft-ietf-uta- > require-tls13. > > > > > [stf] I saw that there was already discussion on this > issue. I > > > > > created a corresponding issue as We will discuss the use > of TLS > > > > > 1.2 and if there is a desire to also allow or existing > pledges, > > > > > that may have no option to only allow TLS 1.3, we would > add a > > > > > note as suggested and explain the necessity. > > > > > > > > > > > > > [Med] ACK. I'm neutral on the outcome here, but I'd like we > back > > > > the design and include some reasoning if we don't follow the > UTA reco. Thanks. > > > [stf] BRSKI-PRM is an extension of existing BRSKI, which > requires > > > TLS 1.2. We aligned with that and also included it in BRSKI- > PRM. > > > TLS1.3 is currently widely used in browsers, but industry > adoption > > > is not as fast. There are constraint devices using SDKs, which > are > > > not updated fast. > > > We enhanced the part with following to state the consideration > of > > > the uta draft.: > > > OLD > > > As already stated in {{!RFC8995}}, the use of TLS 1.3 (or > newer) is > > > encouraged. > > > NEW > > > As already stated in {{!RFC8995}}, and required by {{I-D.ietf- > uta- > > > require-tls13}}, the use of TLS 1.3 (or newer) is encouraged. > > > > > > > [Med] I suggest we pause on this one and reflect the outcome of > the > > ongoing discussion. > [stf] Okay, agreed > > > > > I would at least see in the text a brief mention of the SDK > > limitations you mentioned. > [stf] Yes, it is likely good > > [Med] ACK > > BTW, what is currently supported by implementations such as > open-brski? > [stf] > [Med] It seems this was one was missing. I'm interested, but that's fine if we don't have an answer. Thanks. ____________________________________________________________________________________________________________ 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. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
