Re: [Anima] changes for CORE-SID and SX:structure in draft-ietf-anima-rfc8366bis-04 and -05

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

Hi Michael 

> -----Original Message-----
> Sent: Dienstag, 24. Januar 2023 15:58
> Subject: [Anima] changes for CORE-SID and SX:structure in draft-ietf-anima-
> rfc8366bis-04 and -05
> 
> 
> Did I post this already?
> 
> I have just posted -04, which includes some, but not all, of the BRSKI-PRM
> changes.  I missed the assertion changes in -04, but they are in -05.
Yes, I realized the enhancement in the assertions in section 5.4. 
I was thinking if it would be helpful to also explain the assertion types in the text, but this would somehow replicate the text in the voucher description, which is also part of RFC 8366. 
For assertion types, which are motivated/defined by other documents, I would propose to add a reference to the originating document, also for the handling (agent-proximity would then reference BRSKI-PRM)

The YANG definition of the voucher request (ietf-voucher-request.yang) looks fine from a BRSKI-PRM perspective. The parameters defined are contained. While BRSKI-PRM does not specify further values, I was thinking if equivalent values for the constraint case for 
- agent-provided-proximity-registrar-cert: for constraint also agent-provided-proximity-registrar-pubk and agent-provided-proximity-registrar-pubk-sha256
- agent-sign-cert: for constraint also agent-sign-pubk and agent-sign-pubk-sha256
would make sense to avoid transporting the complete certificates. In BRSKI-PRM we have the agent-sign-cert as optional for the pledge and mandatory for the registrar to address these cases for constraint pledges. But including just pubk or pubk-sha256 would also be an option.
 
> 
> -04:
> In fixing the SID allocations to be consistent (and fixing pyang/sid.py to always
> dump .sid files and list output in SID order.
> The augment mechanism results in a change the leaf path for the voucher-
> request, from:
> 
> /ietf-voucher-request-constrained:voucher/nonce
> to:
> /ietf-voucher-request:voucher/voucher/nonce
> 
> The change from request-constrained to request is anticipated, and I think
> acceptable. (This affects the JSON serialization) But, the additional of an extra
> "voucher" in the path concerns me.
> I tried "augment-structure" as described in RFC 8791, but pyang didn't like it.
> 
> 
> I tried to hack on things with yanglint, but I think it doesn't work.
> 
> rfc8366bis-05:
> * I've also fixed the wrapping in the description so there are no rfc8792
>   wrapped lines. (Kudos to kramdown: it doesn't tell you about 8792 if it
>   doesn't use them)
> 
> * Table 1 is now down up in markdown format.  I'm not sure how to make cells
>   span rows.  I would appreciate someone else to verify the new table 1
>   against RFC8366's version.
I double checked the content of both tables and the one in the PR looks fine. It reflects, what is currently stated in RFC 8366
Format wise, centering the associated cells in a row would increase readability.


> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-
> wg%2Fvoucher%2Fpull%2F22%2Ffiles&data=05%7C01%7Csteffen.fries%40siem
> ens.com%7C96b155c5218c4639287008dafe1b6fb0%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638101691038757391%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C&sdata=EF3rsQs8zKv0IpglR68zoXdfWMs9b2%2FAPy3
> SDBizoqQ%3D&reserved=0
> I'm not going to merge this PR until I get some additional review on the
> differences, and the overall approach to the YANG.
Some observations in addition to the ones above (unsorted regarding importance): 
- section 1 and section 5: jws-voucher may be stated as alternative to the utilized CMS structure in RFC8366
- section 2: proposal to also state the registrar-agent with a reference to BRSKI-PRM
- section 7.2: just food for thought, would it make sense to also allow a nonceless voucher with a list of device serial numbers? This would limit the exchange with the MASA to just one or may be a mean for a pre-provisioned voucher. This would require an array in the voucher definition for the serial number (currently a string). In addition, it may also lead to an enhancement of section 2 regarding voucher-types. 

Observations from ietf-voucher.yang (I'm not a YANG expert):
- the created-on time has been changed to optional? At least this is what I gather from mandatory=false. It is mandatory in the current voucher definition. Not sure regrading the change and if it is necessary to state it explicitly. 
- the expires-on is optional (which is fine) but mandatory=false is not stated. According to RFC 6020, the semantic is the same as not stating it. So we may remove the mandatory=false for the created-on leaf.
- the pinned-domain-cert has been changed to optional (mandatory=false ) as created-on

Best regards
Steffen


> 
> **I AM ASKING FOR A WG CHAIR CONSENSUS CALL**
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.san
> delman.ca%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7C96b155c52
> 18c4639287008dafe1b6fb0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C638101691038757391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=qSuUoEuqiTzKmAlbhd28Fu99djy%2FeVV%2BewJPEeMJMyw%3D&r
> eserved=0        |   ruby on rails    [
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>