[Anima] Re: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS and COMMENT)

["Fries, Steffen" <[e-mail]>]

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: [e-mail] <[e-mail]>
> Sent: Thursday, April 10, 2025 7:11 AM
> To: Fries, Steffen (FT RPD CST) <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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.
>