Misc clarifications needed

Question

Misc clarifications needed

Closed this issue 5 years ago · 15 comments

Section 2.2.
Primary/Secondary ECUs: Terms used to describe the control units within a ground vehicle. A primary ECU downloads and verifies update images and metadata for itself and for secondary ECUs, and distributes images and metadata to secondaries. Thus, it requires extra storage space and a means to download images and metadata. Secondary ECUs receive their update images and metadata from the primary, and only need to verify and install their own metadata and images.

is the metadata for secondaries doubly verified, once by primary and another time by secondary? Or are those two different types of verifications? (e.g. signature vs. just hash). The standard explains that secondaries must verify the metadata for their images; but the definition is misleading.
Terminology needs a metadata definition for this context.

Section 3.2.1 Use cases.

There is no use case listed for when an ECU is swapped with another at a dealer aftermarket. Presumably the director should know about this change for that particular VIN. The difference with this use case is that it’s not OEM-initiated.

Section 5.2.6
“A single mapping indicating that all images (*) MUST be signed by both the Director and Image repository”

Unclear: Single mapping of what to what? Isn’t this just an indication? And, if this is a general Uptane requirement, why does it have to be in a config file? The next paragraph explains it better. Thus this third bullet seems out of place.

Section 5.3.2.1 “The Director MAY encrypt images for ECUs that require it.”

Is there a secure way for an ECU to come with a requirement that images must be encrypted? E.g. serial number, model/type, and image encryption flag. In the standard there are requirements around image encryption but they seem to have nothing to do with the actual Ecu that may or may not require it. The OEM or Tier-n should decide this. O/w these requirements are of limited value.

Answer 1 · 2019-06-24T16:00:50.000Z

@trishankkarthik, @patrickvacek, @plapczyn can one or several of you jump here and review these clarifications?

Answer 2 · 2019-06-25T07:07:26.000Z

is the metadata for secondaries doubly verified, once by primary and another time by secondary? Or are those two different types of verifications? (e.g. signature vs. just hash). The standard explains that secondaries must verify the metadata for their images; but the definition is misleading.
Terminology needs a metadata definition for this context.

Yes, doubly verified. In the full verification case, they are essentially the same verification. In the partial verification case, it is different, which may be why there is some ambiguity here. What is your concern? I'm not sure if I've understand what you mean by needing a "metadata definition".

There is no use case listed for when an ECU is swapped with another at a dealer aftermarket. Presumably the director should know about this change for that particular VIN. The difference with this use case is that it’s not OEM-initiated.

Yes, this is a complicated scenario. IIRC this is mentioned in the deployment considerations. (If it isn't, it probably should be.) In any case, if we were to want to put something about this in the standard, that would probably not be something we could do in time for the 1.0 release.

Is there a secure way for an ECU to come with a requirement that images must be encrypted? E.g. serial number, model/type, and image encryption flag. In the standard there are requirements around image encryption but they seem to have nothing to do with the actual Ecu that may or may not require it. The OEM or Tier-n should decide this. O/w these requirements are of limited value.

This seems implementation-dependent to me. It could belong in deployment considerations. It is possible an appropriate sentence or two could be put in the standard, but anything more than that is probably too complex to get into the 1.0 release.

Answer 3 · 2019-06-25T12:16:32.000Z

Hi, I agree with Patrick that it's too late too make substantial changes to Uptane Standard v1.0. I also think that discussion of many use cases belongs in the Deployment Considerations. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

…

On Tue, Jun 25, 2019 at 3:07 AM Patrick Vacek ***@***.***> wrote: is the metadata for secondaries doubly verified, once by primary and another time by secondary? Or are those two different types of verifications? (e.g. signature vs. just hash). The standard explains that secondaries must verify the metadata for their images; but the definition is misleading. Terminology needs a *metadata* definition for this context. Yes, doubly verified. In the full verification case, they are essentially the same verification. In the partial verification case, it is different, which may be why there is some ambiguity here. What is your concern? I'm not sure if I've understand what you mean by needing a "metadata definition". There is no use case listed for when an ECU is swapped with another at a dealer aftermarket. Presumably the director should know about this change for that particular VIN. The difference with this use case is that it’s not OEM-initiated. Yes, this is a complicated scenario. IIRC this is mentioned in the deployment considerations. (If it isn't, it probably should be.) In any case, if we were to want to put something about this in the standard, that would probably not be something we could do in time for the 1.0 release. Is there a secure way for an ECU to come with a requirement that images must be encrypted? E.g. serial number, model/type, and image encryption flag. In the standard there are requirements around image encryption but they seem to have nothing to do with the actual Ecu that may or may not require it. The OEM or Tier-n should decide this. O/w these requirements are of limited value. This seems implementation-dependent to me. It could belong in deployment considerations. It is possible an appropriate sentence or two could be put in the standard, but anything more than that is probably too complex to get into the 1.0 release. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UO63J2OCHAQSA2ZZN4TP4G727A5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYPIH4A#issuecomment-505316336>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UOYOR6OT4GC6HRMEVGLP4G727ANCNFSM4H27YQ7Q> .

Answer 4 · 2019-06-25T12:18:52.000Z

(Sorry, I'm OOO this week... thanks for covering for me!)

Answer 5 · 2019-06-25T23:31:27.000Z

Thank you very much for your response Patrick. Fully agree it would be too late for changes. Answers are satisfactory and will watch for the opportunity to put them into the Deployment considerations when the time comes. Thanks, Michaela~ From: iramcdonald <notifications@github.com> Sent: Tuesday, June 25, 2019 5:17 AM To: uptane/uptane-standard <uptane-standard@noreply.github.com> Cc: Michaela Vanderveen <mivanderveen@blackberry.com>; Author <author@noreply.github.com> Subject: Re: [uptane/uptane-standard] Misc clarifications needed (#119) Hi, I agree with Patrick that it's too late too make substantial changes to Uptane Standard v1.0. I also think that discussion of many use cases belongs in the Deployment Considerations. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Jun 25, 2019 at 3:07 AM Patrick Vacek ***@***.***> wrote: is the metadata for secondaries doubly verified, once by primary and another time by secondary? Or are those two different types of verifications? (e.g. signature vs. just hash). The standard explains that secondaries must verify the metadata for their images; but the definition is misleading. Terminology needs a *metadata* definition for this context. Yes, doubly verified. In the full verification case, they are essentially the same verification. In the partial verification case, it is different, which may be why there is some ambiguity here. What is your concern? I'm not sure if I've understand what you mean by needing a "metadata definition". There is no use case listed for when an ECU is swapped with another at a dealer aftermarket. Presumably the director should know about this change for that particular VIN. The difference with this use case is that it’s not OEM-initiated. Yes, this is a complicated scenario. IIRC this is mentioned in the deployment considerations. (If it isn't, it probably should be.) In any case, if we were to want to put something about this in the standard, that would probably not be something we could do in time for the 1.0 release. Is there a secure way for an ECU to come with a requirement that images must be encrypted? E.g. serial number, model/type, and image encryption flag. In the standard there are requirements around image encryption but they seem to have nothing to do with the actual Ecu that may or may not require it. The OEM or Tier-n should decide this. O/w these requirements are of limited value. This seems implementation-dependent to me. It could belong in deployment considerations. It is possible an appropriate sentence or two could be put in the standard, but anything more than that is probably too complex to get into the 1.0 release. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UO63J2OCHAQSA2ZZN4TP4G727A5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYPIH4A#issuecomment-505316336>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UOYOR6OT4GC6HRMEVGLP4G727ANCNFSM4H27YQ7Q> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_119-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAMMYW4WOLIA7V45YSQO6D7LP4IECFA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQBEKQ-23issuecomment-2D505418282&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=jPgeDaisaVnK0IHMgv1gkpXmqD90RyApvN6VTRXEDy0&s=XJzxFKOaffbx5gehqbsQVNhXjImPvKbhyYPRu1_zmGo&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMMYW4RSDGJ2VSBC4G3Z723P4IECFANCNFSM4H27YQ7Q&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=jPgeDaisaVnK0IHMgv1gkpXmqD90RyApvN6VTRXEDy0&s=ZD7G9Pfy44AlsBz5RMDhDCJpiG7opC2-j22kGDfVlFk&e=>. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Answer 6 · 2019-06-26T18:24:48.000Z

Agreed in 6/25 mtg to add definition of metadata from NIST (https://csrc.nist.gov/glossary/term/metadata) but those are either circular or not directly applicable. Suggest this, veterans please correct: "Information associated with a role or an image, containing characteristics or parameters thereof: e.g. cryptographic material parameters, file names and versions."

Also agreed to slightly modify the definition of Primary/Secondary ECU to clarify the verification is done by both (added "also".. .sounds a bit strange though):. e.g. "Secondary ECUs receive their update images and metadata from the primary, and only**/also** need to verify and install their own metadata and images."

Answer 7 · 2019-06-26T18:43:45.000Z

Hi Michaela, Thanks very much for your careful reading of the Uptane Standard draft! I like your suggested definition of metadata within the context of Uptane. But, the US NIST Glossary definition at: https://csrc.nist.gov/glossary/term/metadata doesn't look circular or inapplicable to me: "Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels)." I suggest we list *both* definitions - first the NIST one, which is sound information theory, and second the Uptane specialization you proposed. WDYT? Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

…

On Wed, Jun 26, 2019 at 2:24 PM mcvand ***@***.***> wrote: Agreed in 6/25 mtg to add definition of metadata from NIST ( https://csrc.nist.gov/glossary/term/metadata) but those are either circular or not directly applicable. Suggest this, veterans please correct: "Information associated with a role or an image, containing characteristics or parameters thereof: e.g. cryptographic material parameters, file names and versions." Also agreed to slightly modify the definition of Primary/Secondary ECU to clarify the verification is done by both (added "also".. .sounds a bit strange though):. e.g. "Secondary ECUs receive their update images and metadata from the primary, and only**/also** need to verify and install their own metadata and images." — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UOZHON5Q5IU7KMWMKOTP4OX7FA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUNAVI#issuecomment-505991253>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UOZSGS7MZSO4EZID2UTP4OX7FANCNFSM4H27YQ7Q> .

Answer 8 · 2019-06-26T18:48:26.000Z

Hello Ira, Glad you find the NIST one applicable (the “syntax” and “info security labels” seemed strange to me). About the circular nature: the NIST definition of metadata contains 2 counts of the word “metadata”. Thanks, Michaela Vanderveen Senior Standards Manager Mobile +1 (925) 596-8608 Office +1 (925) 242-8563 Email: mivanderveen@blackberry.com<mailto:mivanderveen@blackberry.com> [http://blackberrysquare/articles/2016/2303/sig_tag_1.png] From: iramcdonald <notifications@github.com> Sent: Wednesday, June 26, 2019 11:44 AM To: uptane/uptane-standard <uptane-standard@noreply.github.com> Cc: Michaela Vanderveen <mivanderveen@blackberry.com>; Author <author@noreply.github.com> Subject: Re: [uptane/uptane-standard] Misc clarifications needed (#119) Hi Michaela, Thanks very much for your careful reading of the Uptane Standard draft! I like your suggested definition of metadata within the context of Uptane. But, the US NIST Glossary definition at: https://csrc.nist.gov/glossary/term/metadata doesn't look circular or inapplicable to me: "Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels)." I suggest we list *both* definitions - first the NIST one, which is sound information theory, and second the Uptane specialization you proposed. WDYT? Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

On Wed, Jun 26, 2019 at 2:24 PM mcvand ***@***.***> wrote: Agreed in 6/25 mtg to add definition of metadata from NIST ( https://csrc.nist.gov/glossary/term/metadata) but those are either circular or not directly applicable. Suggest this, veterans please correct: "Information associated with a role or an image, containing characteristics or parameters thereof: e.g. cryptographic material parameters, file names and versions." Also agreed to slightly modify the definition of Primary/Secondary ECU to clarify the verification is done by both (added "also".. .sounds a bit strange though):. e.g. "Secondary ECUs receive their update images and metadata from the primary, and only**/also** need to verify and install their own metadata and images." — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UOZHON5Q5IU7KMWMKOTP4OX7FA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUNAVI#issuecomment-505991253>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UOZSGS7MZSO4EZID2UTP4OX7FANCNFSM4H27YQ7Q> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_119-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAMMYW4Q6D7UPEKOGP65K6HDP4O2GHA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUOXPA-23issuecomment-2D505998268&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=mcwLxKb2TQAHSlwiFdUp-dNNjHoyKktJSCFkQN72ROE&s=lTclA-l8gmM_LS--TRMNk14G8foh33KEWZZJi0Uk60s&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMMYW4SLECNHUWIKLRBZKMTP4O2GHANCNFSM4H27YQ7Q&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=mcwLxKb2TQAHSlwiFdUp-dNNjHoyKktJSCFkQN72ROE&s=xWonkfO9yUWsXnMesBAffLmmSsdTxokmjxOe-pxS1yY&e=>. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Answer 9 · 2019-06-26T18:55:36.000Z

Hi Michaela, I was thinking of "syntax" as being very important in POUF profiles of Uptane implementations. While the NIST definition of metadata contains two instances of metadata, those are in *examples* of classes of metadata - which seemed like useful examples to me, because we use the word metadata in both of these senses in various parts of the Uptane Standard. Cheers, - Ira PS - Running away from this computer to play music all evening at a monthly session at a Moose Lodge 75 miles away. Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

…

On Wed, Jun 26, 2019 at 2:48 PM mcvand ***@***.***> wrote: Hello Ira, Glad you find the NIST one applicable (the “syntax” and “info security labels” seemed strange to me). About the circular nature: the NIST definition of metadata contains 2 counts of the word “metadata”. Thanks, Michaela Vanderveen Senior Standards Manager Mobile +1 (925) 596-8608 Office +1 (925) 242-8563 Email: ***@***.******@***.***> [http://blackberrysquare/articles/2016/2303/sig_tag_1.png] From: iramcdonald ***@***.***> Sent: Wednesday, June 26, 2019 11:44 AM To: uptane/uptane-standard ***@***.***> Cc: Michaela Vanderveen ***@***.***>; Author < ***@***.***> Subject: Re: [uptane/uptane-standard] Misc clarifications needed (#119) Hi Michaela, Thanks very much for your careful reading of the Uptane Standard draft! I like your suggested definition of metadata within the context of Uptane. But, the US NIST Glossary definition at: https://csrc.nist.gov/glossary/term/metadata doesn't look circular or inapplicable to me: "Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels)." I suggest we list *both* definitions - first the NIST one, which is sound information theory, and second the Uptane specialization you proposed. WDYT? Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: ***@***.*** PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jun 26, 2019 at 2:24 PM mcvand ***@***.***> wrote: > Agreed in 6/25 mtg to add definition of metadata from NIST ( > https://csrc.nist.gov/glossary/term/metadata) but those are either > circular or not directly applicable. Suggest this, veterans please correct: > "Information associated with a role or an image, containing characteristics > or parameters thereof: e.g. cryptographic material parameters, file names > and versions." > > Also agreed to slightly modify the definition of Primary/Secondary ECU to > clarify the verification is done by both (added "also".. .sounds a bit > strange though):. e.g. "Secondary ECUs receive their update images and > metadata from the primary, and only**/also** need to verify and install > their own metadata and images." > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #119?email_source=notifications&email_token=AE33UOZHON5Q5IU7KMWMKOTP4OX7FA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUNAVI#issuecomment-505991253>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AE33UOZSGS7MZSO4EZID2UTP4OX7FANCNFSM4H27YQ7Q> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_119-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAMMYW4Q6D7UPEKOGP65K6HDP4O2GHA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUOXPA-23issuecomment-2D505998268&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=mcwLxKb2TQAHSlwiFdUp-dNNjHoyKktJSCFkQN72ROE&s=lTclA-l8gmM_LS--TRMNk14G8foh33KEWZZJi0Uk60s&e=>, or mute the thread< https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMMYW4SLECNHUWIKLRBZKMTP4O2GHANCNFSM4H27YQ7Q&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=mcwLxKb2TQAHSlwiFdUp-dNNjHoyKktJSCFkQN72ROE&s=xWonkfO9yUWsXnMesBAffLmmSsdTxokmjxOe-pxS1yY&e=>. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UO44ZUZRNTYOMOAOBL3P4O2XXA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUPD7I#issuecomment-505999869>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UO73QP5BEEQOEGKOZ4LP4O2XXANCNFSM4H27YQ7Q> .

Answer 10 · 2019-06-28T20:41:29.000Z

I can add this definition as I'm making at capitalization changes.

Answer 11 · 2019-06-29T14:10:05.000Z

Hi Lois, Thanks. Capitalization: Conformance keywords (MUST, SHALL, SHOULD, and *MAY*) must be all-caps throughout. In addition, by IETF BCP 14 rules, they must not be used in lowercase anywhere. In particular, *MAY* is probably still misused in lowercase. IEEE-ISTO PWG and others use "could" or "can" to replace lowerocase "may" where it was not meant to specify a formal conformance option. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434

…

On Fri, Jun 28, 2019 at 4:41 PM Lois Anne DeLong ***@***.***> wrote: I can add this definition as I'm making at capitalization changes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#119?email_source=notifications&email_token=AE33UO6YP3IEYT62XNBNTE3P4ZZPVA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3DU4Y#issuecomment-506870387>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE33UOYPVD4KR6O3V2YLGDLP4ZZPVANCNFSM4H27YQ7Q> .

Answer 12 · 2019-07-02T20:14:48.000Z

PR#125 adds the definition of metadata discussed in this issue. I believe we agreed the other issues here would be moved to the pending deployment issues list. @mcvand, if you want to summarize the other concerns touched on here, I will add them to my offline deployment issues list until our deployment materials have a new home.

Answer 13 · 2019-07-02T20:17:44.000Z

Yes, we agreed that the other issues raised in #119 can be addressed in the deployment considerations later. Thus yes, the offline issue list you are keeping is a good place for now. Should I close this issue now myself or can you? Thanks, Michaela~ From: Lois Anne DeLong <notifications@github.com> Sent: Tuesday, July 2, 2019 1:15 PM To: uptane/uptane-standard <uptane-standard@noreply.github.com> Cc: Michaela Vanderveen <mivanderveen@blackberry.com>; Mention <mention@noreply.github.com> Subject: Re: [uptane/uptane-standard] Misc clarifications needed (#119) PR#125 adds the definition of metadata discussed in this issue. I believe we agreed the other issues here would be moved to the pending deployment issues list. @mcvand<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mcvand&d=DwMCaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=lqukJ7szuuizJIydoF-OrlJv3xnbUnn_45xs3bJbR_s&s=gSFLwWW9WqaK_CHhBNOhgQ6F0gBtO0Y9Dso7avc-B6c&e=>, if you want to summarize the other concerns touched on here, I will add them to my offline deployment issues list until our deployment materials have a new home. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_119-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAMMYW4RBV6WFTEYWRFRTXSDP5OZLVA5CNFSM4H27YQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZCNNZQ-23issuecomment-2D507827942&d=DwMCaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=lqukJ7szuuizJIydoF-OrlJv3xnbUnn_45xs3bJbR_s&s=pphtxUrLvIHEZOFXM9Qz9wV4v6Qc1hQ9GMDvpMGDbSc&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMMYW4TUTTGOKL462XCNF53P5OZLVANCNFSM4H27YQ7Q&d=DwMCaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=KGSG7bfGxf01b4IsGMtVJyl8Kb4u0jPqPkvBvrzkHXg&m=lqukJ7szuuizJIydoF-OrlJv3xnbUnn_45xs3bJbR_s&s=DF-UNp7dqe5qVQNUc_P8C9lD-nw-s7fVUGljVHub7cg&e=>. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Answer 14 · 2019-07-02T20:21:30.000Z

I'm not sure I can close it. I guess you can try, as the creator, but maybe wait till after tomorrow's meeting. Since I referenced this issue in my PR I'm not sure how that might be affected if you close this now. It probably has no effect, but don't know enough about github to be sure.

Answer 15 · 2019-07-03T19:38:29.000Z

This issue can now be closed via PR#125