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://github.com/anima-wg/anima-brski-prm/blob/main/draft-ietf-anima-brski-prm.md).
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
> > > > > # 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
>
> BTW, what is currently supported by implementations such as open-brski?
[stf]
> > > > > ------------------------------------------------------------
> > ----
> > > > > COMMENT:
> > > > > ------------------------------------------------------------
> >
> > > > > # "MUST ...unless" constructs should be "SHOULD ...unless"
> > > > >
> > > > > OLD:
> > > > > To enable interaction as responder with the Registrar-Agent,
> > > > > pledges
> > > > > in responder mode MUST act as servers and MUST provide the
> > > > > endpoints
> > > > > defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
> > > > > path, except for the OPTIONAL endpoint "qps". The endpoints are
> > > > > defined with short names to also accommodate for
> > > > > resource-constrained
> > > > > devices.
> > > > >
> > > > > NEW:
> > > > > To enable interaction as responder with a Registrar-Agent, pledges
> > > > > in responder mode MUST act as servers and SHOULD provide the
> > > > > endpoints
> > > > > defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
> > > > > path, except for the OPTIONAL endpoint "qps". The endpoints are
> > > > > defined with short names to also accommodate for
> > > > > resource-constrained
> > > > > devices.
> > > > [stf] Hm, for compliance with BRSKI-PRM we require the support of
> > > > the two stated endpoints in Table 1 to ensure they can be trigger.
> > > >
> > >
> > > [Med] The issue here is that MUST is an absolute required, while this
> > > case we have an exception (unless..). FWIW, 2119 has the following:
> > >
> > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
> > > definition is an absolute requirement of the specification.
> > >
> > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > > may exist valid reasons in particular circumstances to ignore a
> > > particular item, but the full implications must be understood and
> > > carefully weighed before choosing a different course.
> >
> >
>
> [Med] I see that you explored another path. I like that as well.
>
> There is one nit, though: delete an extra "provide the endpoints"
>
> OLD:
> To enable interaction as responder with a Registrar-Agent, pledges in
> responder mode MUST act as servers and MUST provide the endpoints
> provide the endpoints "tpvr", "tper", "svr", "scac", and "ser"
> defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
> path. The optional endpoint "qps" SHOULD be supported.
>
> NEW:
> To enable interaction as responder with a Registrar-Agent, pledges in
> responder mode MUST act as servers and MUST
> provide the endpoints "tpvr", "tper", "svr", "scac", and "ser"
> defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI
> path. The optional endpoint "qps" SHOULD be supported.
[stf] Good catch, corrected it.
> > > > > # Missing IANA action
> > > > >
> > > > > CURRENT: IANA has registered the following service names
> > > > >
> > > > > Please ad an action for IANA to update that entry. Thanks.
> > > > [stf] We've got the following information from IANA:
> > > > "The actions requested in this document will not be completed until
> > > > the document has been approved for publication as an RFC.
> > > > This message is meant only to confirm the list of actions that will
> > > > be performed."
> > > > Are there additional actions necessary?
> > > >
> > >
> > > [Med] No, just save a question from IANA in the future when they well
> > > implement the actions. Add a sentence to say basically what I
> > had in my comment. Thanks.
>
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
