Subject: [sacm] Proposed [minor] changes to sacm-nea-swid-patnc-1

From: Andreas Steffen <[email-masked]>
Date: Fri, 16 Jun 2017 12:28:23 +0200

Hi,

based on the experience of our SWIMA prototype implementation
we propose four minor changes to the SWIMA draft document
"draft-ietf-sacm-nea-swid-patnc-1".

Best regards

Andreas

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

---

From: Adam Montville <[email-masked]>
Date: Fri, 16 Jun 2017 13:45:21 +0000

Andreas, thank you!

Charles, are you planning to account for these as GitHub issues in the repo
and then update the draft before July 3 with this information (I think
you're already planning to update the draft by then per our last interim)?
https://github.com/sacmwg/software-identification

Kind regards,

Adam

On Fri, Jun 16, 2017 at 5:28 AM Andreas Steffen <
[email-masked]> wrote:

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 20 Jun 2017 16:37:54 +0000

Hi Andreas,

Thanks a bunch for the feedback, and many, many thanks for putting together an implementation of SWIMA.

Regarding your comments:
1) Thank you for noticing the copy-paste errors. I'll get those fixed.

2) Regarding your comment about having length-value fields adjacent to each other: my original thought had been to have all fixed-length fields precede all variable-length fields. I reasoned that by doing this, one could read in all the fixed length fields, and then have all the information necessary to jump to whichever variable length field was of interest, instead of having to do a read-skip-read-skip-read-skip-read-read to get the contents of the fourth variable length field. It sounds like between the fact that A) I am violating typical procedures for data organization, and B) in this case it is unlikely that the reader of the message would care about field 4 but not care about fields 1, 2 and 3, that this design is counterproductive. I have no objection to changing to a more traditional data organization as you propose.

3) I agree that allowing the unknown location to be represented with 0 bytes instead of 8 bytes makes sense.

4) I completely understand and agree with your concerns about starting the software identifier with a length number - definitely not a good thing. I remain a bit nervous about the fact that, while unlikely, it is not impossible for the Tag Creator Regid to include a double underscore, which would cause the decomposition of the software identifier back into its component fields to fail. That said, I understand that this is a theoretical objection to a practical solution. I am also guessing that parties will only rarely have a need to decompose the software identifier into its component fields, and even then a failure of that process would probably not have severe consequences. Thus my objection is a theory of possible minor problems in an edge case. I'm happy to have practical experience override that any day. Barring concerns from others, I'll make the change.

Thanks again for your work and input!

Charles

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Andreas Steffen
> Sent: Friday, June 16, 2017 5:28 AM
> To: [email-masked]
> Cc: Schmidt, Charles M. <[email-masked]>
> Subject: [sacm] Proposed [minor] changes to sacm-nea-swid-patnc-1
> 
> Hi,
>