Hi Francesca, Thank you for taking care of the review! I think the commits in the PR address all my comments.
Best, /Marco On 2020-12-08 16:42, Francesca Palombini wrote: > > Hi Marco, > > > > Thanks, very helpful as always! I have implemented all the comments in > this PR https://github.com/ace-wg/ace-oscore-profile/pull/44 > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F44&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720883194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UPQbvAjheecQ3qFTNZrfA%2F2rXtocuc5U5AQdvhFxxNI%3D&reserved=0> > , if you give me the OK I can merge and upload a new submission. Happy > to see that the comments were about clarifications and editorials. > > > > Inline detailed answers. > > > > Thanks again! > Francesca > > > > *From: *Marco Tiloca <[email protected]> > *Date: *Thursday, 19 November 2020 at 17:04 > *To: *<[email protected]>, Ace Wg <[email protected]> > *Subject: *Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt > *Resent from: *<[email protected]> > *Resent to: *Francesca Palombini <[email protected]>, > <[email protected]>, Göran Selander > <[email protected]>, <[email protected]> > *Resent date: *Thu, 19 Nov 2020 08:03:54 -0800 (PST) > > > > Hello OSCORE profile authors and ACE, > > Please, find below some WGLC comments. Hope it helps! > > Best, > /Marco > > > > Section 1 > > > > * s/is not done by a/is not achieved through a > > > > FP: Ok, fixed. > > > > * s/after the first OSCORE exchange/after the first message exchange > > using OSCORE > > > > FP: Ok, fixed. > > > > Section 2 > > > > * "This specific identifier, encoded as a byte string, is assigned by > > the AS to be unique in the sets of its OSCORE Security Contexts ..." > > > > To avoid confusion, it's probably better to say "unique among the > > issued sets of OSCORE input material", since the AS can have actual > > OSCORE Security Contexts it uses to communicate with Clients or Resource > > Servers. > > > > FP: Ok, fixed. Replaced with OSCORE security input materials > > > > * Referring to 'id' as specific identifier, the text says: "and is not > > used as input material to derive the full OSCORE Security Context." > > > > That's correct, but then the identifier is later included in Table 1 > > "OSCORE_Input_Material Parameters" :-) > > > > Perhaps it's fine to just revert to OSCORE_Security_Context_Object, > > both for the name of Table 1 and in different spots of the text? They > > would still consider 'id' as OSCORE Input Material Identifier, while > > aligned with the registry name from Section 9.4. > > > > FP: I see your point, but the name was source of discussion before and > I'd rather not go back on that. I don't think it is a problem that the > 'id' is both part of the "OSCORE_Input_Material" object and also not > part of the actual input material. After all it needs to be part of > the object to identify it. What I did is to change its CBOR label > though, to have it as 0, since I think that makes more sense that to > be in the middle of other input materials. Note that this is a change > that will affect implementations. > > > > * s/If the request verifies/If the request is successfully verified > > > > FP: Ok, fixed. > > > > * s/until token expiration/until token deletion, due to e.g. expiration > > or revocation > > > > FP: thanks for this comment. I did only keep expiration as example, > > > > * s/the same or different/the same or a different one > > > > FP: Ok, fixed. > > > > * Figure 1 can also show the achievement of mutual authentication, > > following the OSCORE exchange at the end > > > > FP: Good point, added. > > > > > > Section 3.1 > > > > * s/object. kid field carrying/object, with the kid field carrying > > > > FP: Ok, fixed. > > > > Section 3.2 > > > > * "... profile negotiation can be omitted" - I think "profile signaling" > > better reflects what may happen here, see also the beginning of the > > paragraph. > > > > FP: Ok, fixed. > > > > * s/in the the/in the > > > > FP: Ok, fixed. > > > > * s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token > > > > FP: Ok, fixed. > > > > Section 3.2.1 > > > > * In the text entries following Table 1, the CBOR integer labels need to > > be aligned with the CDDL summary at the end of the section. > > > > FP: I think it was? Now I moved id to index 0, so I switched the order > there too. > > > > * s/This parameter identifies the OSCORE_Input_Material/This parameter > > identifies the OSCORE_Input_Material object > > > > FP: I will let the RFC editors decide on that one :) Don't want to > become too verbose if it's not needed. > > > > * s/the "id" type is byte string/the "id" type is bstr > > > > FP: ah, good point. I actually changed all the description to extend > the type (so byte string instead of bstr, etc), in order not to use > CDDL in text. > > > > * This version -13 has removed 'clientId' and 'serverId' from Table 1 > > and thus as code points from the "OSCORE Security Context Parameters" > > registry. > > > > No strong need to include them back, but even if this profile does not > > use them and does not send them on the wire, I think they still belong > > to the same namespace, since they are descriptive of a security context > > and are in fact also used as input material to derive it :-) > > FP: I agree with that, and think the first draft to use them will > register them. The registration of the OSCORE_Input_Material does not > specify how this material is used, that is up to the draft describing > the derivation process, so it does not make sense to register them > here without explaining the derivation process using those parameters. > > > > Section 4 > > > > * s/the RS and client authenticates themselves/the RS and client > > authenticate each other > > > > FP: Ok, fixed. > > * s/successfully verified the response from the RS/successfully verified > > a response from the RS as protected with the established OSCORE context > > > > (similar occurrences are also later in the text) > > > > FP: Ok, fixed. > > > > Section 4.1 > > > > * In the first paragraph, I suggest to rephrase as "and the posted > > access token is still retained". > > > > That doesn't require to explicitly mention "valid", since asserting > > especially validity can be non-trivial for the client, e.g. in case of > > Token revocation. > > (similar occurrences are also later in the text) > > > > FP: I am not sure about this one: I don't think talking about > "retaining" an access token is precise enough (a token might be > "retained" in memory, but expired). "Valid" to me seems less > ambiguous. I would expect implementations to have a way to mark token > as valid or non valid (e.g. if expired or revoked). What woud be > difficult for implementations to assert validity? > > * In the second paragraph, I suggest to extend the ending as: > > > > "... makes sure that it does not collide with any of its Recipient IDs > > currently used. These include also Recipient IDs used as ID1 value for > > ongoing executions of this profile." > > > > FP: Good point, I think I got it. Rephrased it with " nor with any > other identifier ID1 if the client is executing this exchange with a > different RS at the same time." > > * s/the client MUST wrap the token and N1 in a CBOR map/the client MUST > > wrap the token, N1 and ID1 in a CBOR map > > FP: Ok, fixed. > > > > * s/using the "access_token" parameter/using the 'access_token' parameter > > > > FP: Ok, fixed. > > > > * In the sixth paragraph, the last sentence says "... as different > > nonces will be used." Doesn't the client and the RS also negotiate new > > IDs like they did in the first posting of the same original token? > > > > FP: yes, but the client might decide to reuse the same ID, I don't > really see a problem with that. > > > > * In the last paragraph: "The client MUST only send the access token in > > the payload, no nonce or identifier are sent." > > > > Just to be sure, can you expand on this request format? I suppose the > > client still uses Content-Format "application/ace+cbor", just including > > only the 'access_token' entry in the map. Correct? > > > > FP: Yes that is correct. The request is the same as in Figure 10 with > the exception that it is protected with OSCORE and that no nonce nor > ids are sent. > > > > * In the last paragraph: "... the RS will replace the old token with the > > new one, maintaining the same Security Context." > > > > This replacement step can be expanded for clarity. A simple 1-to-1 > > replacement would overwrite also the stored 'cnf' claim from the > > original token, among other things. So it should be more about > > selectively replacing some information originally coming the first > > token, while keeping some other from it. What to actually replace should > > include, for instance, information related to access rights (e.g. > > scope), and to the new token's lifetime (exp, exi). > > > > FP: I believe what you were commenting here (i.e. the RS behavior) is > actually described in details in section 4.2, starting with "If the RS > receives the token in a OSCORE protected message...". I only want to > give the intuition here, focusing more on the client without go into > the details of what the RS has to do as a consequence, which is why I > am tempted to not make a change here. But if you think something is > missing from 4.2, let me know and I'll see if we can expand there. > > * While reading this, I was wondering if one could repost the same first > > token to rekey the OSCORE context. This is mentioned at the end of > > Section 4.3, but anticipating the possibility here and adding a forward > > pointer to Section 4.3 would help. > > > > FP: I added a paragraph in section 4.1 (starting with "The client may > also chose to re-POST the access token...") > > > > Section 4.1.1 and Section 4.1.2 > > > > * The first sentence captures the case where the first token is posted > > or re-posted. It can be rephrased to cover also the posting of a token > > for updating access rights, where these parameters are not included. > > > > FP: Ok, added text at the end of the sentence. > > > > Section 4.2 > > > > * "any of the mandatory parameters from the AS or the identifier) ..." > > > > It's worth making it explicit that the mentioned identifier is 'id'. > > > > FP: I actually meant the identifier id1. Added it. > > > > * s/in the 'osc'/in the 'osc' field > > > > FP: Ok, done. > > > > * "... the RS must respond" --- Should this not be a MUST ? > > > > FP: No, this requirement comes from the framework, so it is non > normative (the normative one is "The RS MUST follow the procedures > defined in section 5.8.1 of > > [I-D.ietf-ace-oauth-authz]") > > * s/is different from the ace_client_recipientid/is different from the > > value specified in the received 'ace_client_recipientid' parameter > > > > FP: Ok, done. > > > > * Second paragraph after Figure 11 > > > > - s/MUST discard/MUST ignore > > > > FP: Ok, done. > > > > - s/the "cnf" parameter of/the 'cnf' claim of > > > > FP: Ok, done. > > > > - s/matches the OSCORE Input/matches with the identifier of the > > OSCORE Input > > > > FP: Ok, done. > > > > - Related to a previous comment about token replacement, some > > information has to be retained from the first token, as not present in > > the new one. > > > > FP: I am not sure how to implement this comment without making it very > hard to read. I trust readers at this point will understand what > "discard the old token and associate the new token" means. > > > > -s/in the "cnf" parameter/in the 'cnf' claim > > > > FP: Ok, done. > > > > * It can happen that all is fine for the RS, it installs the OSCORE > > Security Context, it responds to the client, and the response gets lost. > > In this case: > > > > - After a timeout expiration, can the client simply repost the same > > token as mentioned at the end of Section 4.3? This can be another reason > > for reposting the original token, to mention in the sixth paragraph of > > Section 4.1. > > > > FP: Yes, added. > > > > - Should the server delete the token and the OSCORE Security Context, > > if not receiving an OSCORE protected request from the client before a > > timeout expires? After all, it's reasonable to assume that a client > > sends a request right away or not long after the token post is > > completed. If this is included, it would be one more point in the bullet > > list for the RS in Section 6. > > > > FP: It is reasonable, however I don't want to add it to Section 6 as I > don't want to make it a requirement to the RS. It is up to > applications to define policies for such a timeout. We make it clear > that it's only after the first OSCORE exchange has happened that C and > RS are assure that the exchange succeeded. How long to wait, I think > should be out of scope. > > > > Section 4.2.1 and 4.2.2 > > > > * The first sentence captures the case where the first token is posted > > or re-posted. It can be rephrased to cover also the posting of a token > > for updating access rights, where these parameters are not included. > > > > FP: Ok, done > > > > Section 4.3 > > > > * s/Secret from the parameter, received/Secret from the parameter received > > > > FP: Ok, done > > > > * If the client stops the exchange, it should also unlock the ID1 value > > previously offered. > > > > FP: I believe this is implementation details. I think this should be > covered by the clarifications above. > > > > * s/to RS/to the RS > > > > FP: Ok, done > > > > * The end of the last paragraph mentions possibly reposting the same > > first token to rekey the OSCORE context. Consistently with the fourth > > paragraph of Section 4, I suggest to mention here again that this > > request is not protected, since not related to updating access rights. > > > > FP: Ok, done > > > > Section 5 > > > > * s/profile, other/profile, but other > > > > FP: s/,/; instead, but done > > > > Section 6 > > > > * s/context expires/context expires or is revoked (2 instances) > > > > FP: Again, I am hesitant to add revoked here, as the framework barely > touches on revocations of tokens, and explicitely states that > expiration is the norm instead. > > > > * In the fourth bullet point, isn't this actually fine if the reposted > > token is exactly the original first token? In that case, new nonces (and > > I guess also IDs) are exchanged. > > > > FP: This is fine, but it means the RS is wishing to re-derive a new > context, so the old one must be discarded. > > > > * I think there should be one more bullet point in the client list, for > > when the client receives back ID2 == ID1 from the RS, after having > > reposted the original first access token. > > > > (This relates to a previous comment for Section 4.1; I thought a > > reposting of the first original token involves an exchange of new nonces > > as well as of new IDs) > > > > FP: Why? I don't understand why this is not already covered. Ah ok so > maybe this is not valid anymore? > > > > Section 7 > > > > * s/usecase/use case > > > > FP: Ok, done > > > > * s/for a client/for a same client (2 instances) > > > > FP: Ok, done (I am sure the RFCEditor will change this to something > else too :) ) > > > > * I think it's better to expand C and Cs to "client" and "clients" > > > > FP: Ok, done > > > > On 2020-11-08 23:51, Daniel Migault wrote: > > Hi, > > > > This email starts a WGLC for the draft > draft-ietf-ace-oscore-profile until Monday November 23. We would > like to send the document back to the IESG with sufficient > confidence, so please take the time to review it carefully provide > comments and feed backs. > > Note that also that the document (13) is being reviewed by the > security directorate. > > > > Yours, > Daniel > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D561b951b-0980ac2a-561bd580-86e2237f51fb-7e8ff0f2b460277b%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qok50i4u7VVFEl1OFeUXLRKDiGgpbk4dLbpvkU6Bei4%3D&reserved=0> > > > > ---------- Forwarded message --------- > From: <[email protected] <mailto:[email protected]>> > Date: Tue, Oct 27, 2020 at 12:14 PM > Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt > To: <[email protected] <mailto:[email protected]>> > Cc: <[email protected] <mailto:[email protected]>> > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication and Authorization > for Constrained Environments WG of the IETF. > > Title : OSCORE Profile of the Authentication and > Authorization for Constrained Environments Framework > Authors : Francesca Palombini > Ludwig Seitz > Göran Selander > Martin Gunnarsson > Filename : draft-ietf-ace-oscore-profile-13.txt > Pages : 32 > Date : 2020-10-27 > > Abstract: > This memo specifies a profile for the Authentication and > Authorization for Constrained Environments (ACE) framework. It > utilizes Object Security for Constrained RESTful Environments > (OSCORE) to provide communication security and proof-of-possession > for a key owned by the client and bound to an OAuth 2.0 access > token. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D577dc830-08e6f101-577d88ab-86e2237f51fb-0882f337db2a5b4a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zruCrjBZvRmdiFa4COi2psW7iHU4V63fVCOxILxDSyk%3D&reserved=0> > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13 > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D76148db7-298fb486-7614cd2c-86e2237f51fb-6db7a86c1af38e00%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Ftools.ietf.org%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DOaxJICL6Bp%25252Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hp433XpyJUn9JsGQChpyoRYt4cJfZJ38YcBps34MEWc%3D&reserved=0> > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13 > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D6a06d0a5-359de994-6a06903e-86e2237f51fb-61db490b8c9907fa%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253D7Ac6UdrbH6IBIcm2%25252BYWd4iwufwIblv76Nq4VretJZuw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m3u076VCs%2FiJaJhjlmeJ7TU6wD0pmnt5gqOvx092rZY%3D&reserved=0> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13 > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D71594c3d-2ec2750c-71590ca6-86e2237f51fb-f0c9e033402ad200%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Frfcdiff%25253Furl2%25253Ddraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DR%25252Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720913129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F8QwAqDXoF0BILw9dlX81bR1mf5A%2FEnqzxPu%2FIYtGWM%3D&reserved=0> > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dca0c6a74-95975345-ca0c2aef-86e2237f51fb-f8b34619f6d31a0a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttp%25253A%25252F%25252Ftools.ietf.org%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253Dpec0ClOMPHj%25252BsHa%25252ByDBFOvDj90aPwlcEURCcQI6igxI%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UpddxCFd%2B31znTW3iXzzX2xacrnj6GRnHhJher5nX3E%3D&reserved=0>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dec181a40-b3832371-ec185adb-86e2237f51fb-0c8012effe9f8cf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dftp%25253A%25252F%25252Fftp.ietf.org%25252Finternet-drafts%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DAJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RCz5%2FveS9uLDPSZ3vKyXGniIfA%2Bled5V4tVIZ8lihQY%3D&reserved=0> > > > _______________________________________________ > Ace mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ace > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D8c63f3f8-d3f8cac9-8c63b363-86e2237f51fb-12f198f7f4eaea38%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DwMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%25252BPNHeDVg%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BSo5ma5lttya0kAzk8VDD9KHRlptjqENzbl%2FSyVf9xM%3D&reserved=0> > > > > > -- > > Daniel Migault > > Ericsson > > > > _______________________________________________ > > Ace mailing list > > [email protected] <mailto:[email protected]> > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&reserved=0 > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1b3a6707-44a15e36-1b3a279c-86e2237f51fb-a3272a3cd4614bf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526amp%253Bdata%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981024818%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526amp%253Bsdata%253DSlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%25253D%2526amp%253Breserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qtS%2BkSgOGR5xYUBZJzmjz4uRcoTaPvsOOkwqYWwvFMs%3D&reserved=0> > > > > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistagången 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1ed65bc0-414d62f1-1ed61b5b-86e2237f51fb-af23a91f66f28bf9%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Fwww.ri.se%252F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720942944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Zqn8Rl0IDx8BQ%2BgAeZ9t8%2BQYkSVkdg3qqtnWWo7kla8%3D&reserved=0> > > _______________________________________________ > Ace mailing list > [email protected] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720972812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rr8CAJby1Nbe7VD2Hyl%2FxhrfQ8wU4SwB21y%2B06NdP2U%3D&reserved=0 -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
