Hi Steffen, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Fries, Steffen <steffen.fr...@siemens.com> > Envoyé : lundi 7 avril 2025 18:14 > À : 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) > > > Hello Mohamed, > > Thank you for the review and the feedback. > Regarding the nits you sent, we will address them in the next > version of the document. > > I put my comments inline > > Best regards > Steffen > > > -----Original Message----- > > From: Mohamed Boucadair via Datatracker <nore...@ietf.org> > > Sent: Sunday, April 6, 2025 5:04 PM > > Subject: Mohamed Boucadair's Discuss on draft-ietf-anima-brski- > prm-18: > > (with DISCUSS and COMMENT) > > > > > > ---------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------- > > # DISCUSS > > > > # Unconditional MUST > > > > CURRENT: > > The pledge MUST respond to all requests regardless of the > > Host header field provided by the client (i.e., ignore it). > > > > I don't think that is safe. > > > > I'm afraid this needs some scoping; as there are other > legitimate > > conditions where the pledge doe snot have to reply. > [stf] Based on the existing discussion on this, we opened an issue > on github to align on the solution > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F136&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977500974%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6t59MA7TXOc6K8UqDWNIdB4AcNmChZ > kMfunB286iFvQ%3D&reserved=0). The current proposal takes your > suggestion into account: > OLD > The pledge MUST respond to all requests regardless of the Host > header field provided by the client (i.e., ignore it). > > NEW > In the absence of a security policy the pledge MUST respond to all > requests regardless of the Host header field provided by the > client (i.e., ignore it). A security policy may include a rate > limiting for a requests to avoid susceptibility of the pledge to > overload. > > Once aligned, we will include it in the draft [Med] ACK. > > > > # 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: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F137&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977521493%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i%2B4HkuwPdz9psQko2w%2BKFOo64w > xCycDViH8xn0iO8cc%3D&reserved=0 > From RFC 9205 I understood that we could use the HTTP status codes > in this way > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9205%23section- > 4.6&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ceddc725b341946 > fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8796392977530669%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=30Wv7lV48UnxMlpMa9wQB7ripnoM8kKJ4%2BmYwBvrggY > %3D&reserved=0 ) 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. > > > > There are several similar constructs in the document. > > > > # 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 > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F138&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977539661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=atD1nebKphWi1qh3MFPKoD71vn%2BU > hncvx%2BJ%2Bu0s9fBE%3D&reserved=0) to discuss optimization in > handling of the documents. > > [Med] ACK. > > > > # 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 > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F139&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977548468%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WqjjxqsAWc9oufFDjJGYsHRdYK9cku > v2CnKiUb5yHrA%3D&reserved=0 > 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. > > > > > > ---------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------- > > > > # Consider having a reference figure early in the document with > the > > various entities. > [stf] We currently have the architecture overview figure in > section 5 discussing the solution architecture. To avoid repeating > that figure, would it be fine to essentially reference the figure > from the introduction to guide the reader to the overview? > [Med] Moving that figure early in the document would be better, IMO. > > > # Be consistent through the document about how you expand as > both > > forms are > > used: Xccc Xccc Xcc (XXX) or XXX (Xccc Xccc Xcc). > [stf] okay, we will double check the referencing. Changed > according to proposals in the NITs. > [Med] Thanks. > > > # Entities are functional one: There might be multiple servers, > RAs, > > pledges, etc. Consider fixing this through the document. For > example: > > > > OLD: > > EST in turn > > relies for the authentication and authorization of the > certification > > request on the credentials used by the underlying TLS between > the EST > > client and the EST server. > > NEW: > > EST in turn > > relies for the authentication and authorization of the > certification > > request on the credentials used by the underlying TLS between > the EST > > client and an EST server. > > > > OLD: BRSKI addresses scenarios in which the pledge initiates the > > NEW: BRSKI addresses scenarios in which a pledge initiates the > > > > OLD: > > * introduces the Registrar-Agent as new component to > facilitate the > > communication between the pledge and the domain registrar. > > > > NEW: > > * introduces the Registrar-Agent as new component to > facilitate the > > communication between the pledge and a domain registrar. > > > > OLD: is cryptographically bound to the end entity (EE) > certificate. > > NEW: is cryptographically bound to an end entity (EE) > certificate. > [stf] agree to all of the above. Will be changed accordingly. > > > Etc. > [stf] we will look for further places to ensure openness to > utilize multiple instances > [Med] ACK. > > > # Consider providing an example of non-IP > > > > CURRENT: > > * also enables the usage of alternative transports, both IP- > based > > and non-IP, > > [stf] we discussed connectivity via Bluetooth or NFC and can > include it as example. > Would lead to > NEW > * also enables the usage of alternative transports, both IP- > based > and non-IP (e.g., Bluetooth-based or NFC-based > communication), > > [Med] Thanks. > > # Capability management: > > > > CURRENT > > There may be pledges that can support both modes, initiator > and > > responder mode. In these cases, BRSKI-PRM can be combined > with BRSKI > > as defined in [RFC8995] or BRSKI-AE [I-D.ietf-anima-brski-ae] > to > > allow for more bootstrapping flexibility. > > > > Do we need to expose these capabilities to a management system? > How this can > > be managed/controlled? > [stf] good point, we address this capability exchange options > later on in the discovery section by referencing the ongoing work > on BRSKI-Discovery, but keeping it at a minimum in BRSKI-PRM. The > BRSKI-Discovery discusses solutions for all existing variants of > BRSKI > > Proposal to add after the stated sentence > NEW > Providing information about capabilities of BRSKI components like > the pledge or registrar is handled as part of the discovery. > BRSKI-PRM relies only on a minimum necessary set of capabilities > for the interaction and leaves the definition of more advanced > mechanisms allowing to signal specific capabilities to [I-D.ietf- > anima-brski-discovery]. > [Med] Deal! > > > # Not a definition > > > > CURRENT: > > CSR: Certificate Signing Request. > > > > This is not a definition. May be point to the RFC you cited in > the doc. > [stf] We do this in later sections of the document, but it is good > to also include it here. > OLD > CSR: Certificate Signing Request. > NEW > CSR: Certificate Signing Request, as defined in [RFC2986]. > [Med] Better, thanks. > > > # Resource vs. Endpoint > > > > CURRENT: > > endpoint: Term equivalent to resource in HTTP [RFC9110] and > CoAP > > [RFC7252]. Endpoints are accessible via Well-Known URIs > > [RFC8615]. > > > > For the CoAP mention, this may be confusing as CoAP has also the > concept of > > "Endpoint", which is not identical to resource. > [stf] Do you have a suggestion on how to address potential > confusion here? We tried this already by providing references to > both RFCs, but if there is a clearer way of describing it we could > include it. [Med] I would simply remove the mention of CoAP here. No need to dive into subtleties of endpoint vs. resources for a protocol that is not used as foundation for this work. > > > > # Lack of reference > > > > CURRENT: > > mTLS: mutual Transport Layer Security. > > > [stf] proposal to enhance the description to > OLD > mTLS: mutual Transport Layer Security. > > NEW > mTLS: mutual Transport Layer Security, refers to mutual > authenticated TLS as specified in [RFC 8446]. [Med] ACK. > > > # Unfortunate acronym > > > > PoP: Unfortunate as this one is widely used for Point of > Presence. No need to > > change anything, though. > [stf] hm, that is unfortunate indeed, but proof-of-possession > (PoP) is already used in other RFCs (RFC 7030, RFC 9483) and we > aligned with that terminology. > > > > # Consistency > > > > OLD: Registrar_Agent > > NEW: Registrar-Agent > [stf] good catch, most importantly, it needs to be correct in the > terminology section. Changed as suggested. > [Med] ACK > > > # Mysterious > > > > CURRENT: Requirements Discussion and Mapping to Solution- > Elements > > > > What does Solution-Elements mean? > [stf] In the discussion we handled solution elements as "parts of > the solution" like the introduction of the registrar-agent as new > component or the reliance on self-contained objects, enhancements > of assertion types in the voucher etc. If you have a proposal for > a better name, we could change it. > [Med] Thanks for clarifying. I think I would s/Solution-Element/BRSKI-PRM Functional Entities or similar. > > > # Thanks! > > > > CURRENT: > > An abstract overview of the BRSKI-PRM protocol can be found > on slide > > 8 of [BRSKI-PRM-abstract]. > > > > That figure is helpful. I didn't checked though that all the > steps are still > > valid in the latest version of the spec. I trust you have done > that check. > [stf] yes, the steps are still fine. We did no include the details > on the data objects but the exchanges are still valid. > [Med] Thank you for confirming. > > # Outsource Key Infrastructure > > > > This is currently drawn within the customer domain. Can this be > > outsourced/external to the customer domain? > [stf] The intention was to show the supporting infrastructure on > the customer side without including the operational model. So the > PKI may be customer operated or provided to the customer as > service. > [Med] Please consider clarifying this in the ops section. Thanks. > > > # HTTP(S) > > > > CURRENT: the pledge and the Registrar-Agent is assumed to be > HTTP(S) > > > > In which case the non-secure mode is allowed? > [stf] The communication between the pledge and the registrar-agent > is protected by relying on self-contained objects for the > integrity protection. So it is not "non-secured". TLS is intended > to provide confidentiality protection if needed. As the pledge in > BRSKI-PRM would act as server, it needs a certificate (this is at > least what we targeted for BRSKI-PRM) to authenticate accordingly. > This comes with certain boundary conditions for the handling, > which we put together in Annex B: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-brski-prm- > 18.html%23pledgehttps&data=05%7C02%7Cmohamed.boucadair%40orange.co > m%7Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6 > f5d20%7C0%7C0%7C638796392977557238%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SrqZXhjTBSJ46GqTwXsZosseJnV > guVWUAGycpA9hgUI%3D&reserved=0 [Med] Thanks. > > > # Group OPS considerations in one single section > > > > Consider moving the following to the OPS cons section: > > > > CURRENT: > > The benefits of BRSKI-PRM can be achieved even without the > > operational complexity of stand-alone Registrar-Agents by > integrating > > the necessary functionality of the Registrar-Agent as a > module into > > the domain registrar as shown in Figure 3 so that it can > support the > > BRSKI-PRM communications to the pledge. > > [stf] Good idea! Included the following in the Ops Con section: > NEW > As outlined in {{colo-regagt}} the functional support of BRSKI-PRM > can also be achieved using a Registrar-Agent co-located with the > Registrar instead of a stand-alone Registrar-Agent, which may > reduce operational complexity. > > > > And > > > > CURRENT > > Overall, this may have > > operational implications when the registrar is part of a > scalable > > framework as described in Section 1.3.1 of > > [I-D.richardson-anima-registrar-considerations]. > [stf] The reference to [I-D.richardson-anima-registrar- > considerations] is already contained in the Ops Con. > So I would propose to move the sentence as suggested to the Ops > Con section as following to keep the context: > NEW > Requirements to the utilized credentials authenticating and > artifact signatures on the registrar as outlined in Section 6.3 > may have operational implications when the registrar is part of a > scalable framework as described in Section 1.3.1 of [I- > D.richardson-anima-registrar-considerations]. > [Med] This is an enhancement as we do have one reference section to look at for these important matters. > > # Need concrete behavior > > > > CURRENT: Further, the Registrar-Agent SHOULD have synchronized > time. > > > > Should we provide more concrete behavior here? > [stf] We have certain considerations added for the pledge, that > may have no synchronized time, but not for the registrar-agent. > I created an issue > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F140&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977566988%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=A%2FAsfvGfLwEjULaUAA9sVInsIUus > BFyB3u8Uuk%2Ff9k8%3D&reserved=0) to discuss the further approach > as there exist different options > [Med] ACK. > > > # Non-discovery > > > > CURRENT: > > 6.1.1. Discovery of the Registrar > > > > This is more about non-discovery :-) > > > > Consider changing to "Explicit Configuration of Registrars" > [stf] Well, besides the configuration, there is also the reference > to the standard discovery approach as already specified in RFC > 8995 and the pointer to the BRSKI discovery draft for a more > flexible discovery my feeling is it would be good to keep the > naming. > [Med] Let' not change then. > > > # hostname and intermittent connectivity > > > > CURRENT: > > While the Registrar-Agent requires the IP address of the > domain > > registrar to initiate a TLS session, a separate discovery of > the > > registrar is likely not needed and a configuration of the > domain > > registrar IP address or hostname is assumed. > > > > How to reconcile this with the intermittent connectivity > condition mentioned > > early in the document, including with a name resolution service > which may not > > be reachable? > > > > BTW, multiple IP addresses may be available. Consider updating > to: > > > > NEW: > > While the Registrar-Agent requires an IP address of the > domain > > registrar to initiate a TLS session, a separate discovery of > the > > registrar is likely not needed and a configuration of the > domain > > registrar IP address or hostname is assumed. > [stf] I would be fine with the suggested text. > [Med] OK. > > > # Configurable knobs > > > > CURRENT: > > In the absence of a more general discovery as defined in > > [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use > > > > Do we need to have a control parameter here to instruct the > behavior of the RA? > [stf] This is covered in the referenced draft. It allows to > discover the functionality of the registrar with much more details > about operational mode, encoding options, etc. > Would you suggest to provide a sentence that the discovery may be > a configuration item of the Registrar-Agent. I had assumed this is > already implicitly given through the existing formulation, but > explicit may be better. [Med] Adding that sentence would be may preference here as a reader. > > > The same applies for the following: > > > > CURRENT: > > A nonceless voucher MAY be accepted as in [RFC8995] if > allowed by the > > pledge implementation of the manufacturer. > [stf] As above, the suggestion is to include a sentence that the > manufacturer may opt to have this as configuration item? > [Med] Yeah. Thanks. > > > # Expired I-Ds > > > > CURRENT: e.g., as proposed in [I-D.richardson-emu-eap- > onboarding]. > > > > I suggest to remove citations of expired individual I-Ds. > [stf] Yes, we could remove it as it is just intended as example. > Will double check with Michael if there will be an update of the > draft > [Med] Thank you. > > # "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. > > (also s/the/a) > [stf] done in the original text > [Med] Thanks. > > > # Redundant language (many occurrences in the text) > > > > OLD: Optionally, TLS MAY be used to provide transport security > > NEW: TLS MAY be used to provide transport security > [stf] Thank you, done as suggested for all occurrences. > [Med] ACK > > > # TTL > > > > CURRENT: > > Note that the pledge provisionally accepts the registrar EE > > certificate contained in the tPVR until it receives the > voucher (see > > Section 5.4). > > > > Shouldn't that be TTLed as well for better security control? > [stf] Good point we need to discuss this to avoid a dead lock of > the pledge. As the situation is different to the TLS connection in > BRSKI we may add some further clarification. Created issue for > discussion > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fanima-wg%2Fanima-brski- > prm%2Fissues%2F142&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Ceddc725b341946fbca5008dd75ef55af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638796392977575689%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gfUuod7F2FJm3CQbFDHGctbqROf%2F > yuDeMubdxf4perM%3D&reserved=0 > [Med] ACK. > > > # Inappropriate use of normative language > > > > CURRENT: > > The following assumes that a Registrar-Agent MAY need to > query the > > overall status of a pledge. > > > > This is an assumption, s/MAY/may > [stf] yes, true. Changed to lower case. > [Med] ACK. > > > # Rate-limit log actions > > > > CURRENT: > > The registrar SHOULD log certain events to provide an audit > trail for > > the onboarding of pledges into its domain. > > > > In order to protect the registrar from overload attacks, > consider adding a > > rate-limit guard for logging the same event. > [stf] Added the following at the end of the section > NEW > In order to protect the registrar from overload attacks, a rate- > limiting may be used by logging events from the same type just > once. > [Med] Looks good to me. > > # 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. > > # You are allowed to not use the template! > > > > CURRENT: > > The use of YANG to define data structures via the [RFC8971] > > "structure" statement, is relatively new and distinct from > the common > > use of YANG to define an API accessed by network management > protocols > > such as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this > reason, > > these guidelines do not follow the template described by > Section 3.7 > > of [RFC8407] (Security Considerations). > > > > You can delete this text. 8407bis have the required provisions > for you :-) > > > > Documents that define exclusively modules following the > extension in > > [RFC8791] are not required to include the security template > in > > Section 3.7.1. Likewise, following the template is not > required for > > modules that define YANG extensions such as [RFC7952]. > [stf] Updated the text as suggested > [Med] Thanks > > > > > Hope this helps. > [stf] definitely, again thanks for the review. > > > > Cheers, > > Med > > > > ____________________________________________________________________________________________________________ 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
