clarification section 4.1

[mglt]

4.1. UAS Remote Identifiers Problem Space

I understand a binding/proxy/translation is needed between the HHIT and X509. If that is correct, it seems that that needed to be defined by the DRIP WG. If we do not have anty document addressing this issue, we need to clarify whether that is something we need or not and eventually reword the text "must be devised".

[ShuaiZhao]

@mglt I dont think we have defined such documents/method to bind HHIT and X.509. @bob can clarify.

per @evyncke suggestion, we should not use normative wording in the informational draft anyway. Can I propose to use "could be devised"?

[boucadair]

Shuai, This is a good comment from Daniel given that interoperating with other systems may break. I don’t think that changing must/could is appropriate here. Also, please note that “must” is not a normative language, but these listed in Section 2 are: == 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown above. == This is not an IETF rule, but a rationale I’m following as an IETF contributor: If we are defining just **an** architecture for DRIP, then I would avoid using the normative language. If we are defining **the** DRIP architecture, it makes sense to use the normative language for clarity and spotting key aspects that are required for the architecture to be effective. If we decide to not use the normative language, then Section 2 should be removed. Cheers, Med De : Shuai Zhao ***@***.*** Envoyé : samedi 26 juin 2021 03:34 À : ietf-wg-drip/draft-ietf-drip-arch ***@***.***> Cc : BOUCADAIR Mohamed INNOV/NET ***@***.***>; Mention ***@***.***> Objet : Re: [ietf-wg-drip/draft-ietf-drip-arch] clarification section 4.1 (#20) @boucadair<https://github.com/boucadair> I dont think we have defined such documents/method to bind HHIT and X.509. @bob<https://github.com/bob> can clarify. per @evyncke<https://github.com/evyncke> suggestion, we should not use normative wording in the informational draft anyway. Can I propose to use "could be devised"? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#20 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADXR6V6EVJDRFBSDLAFY6GDTUUVAFANCNFSM46H3YNNQ>.

…

_________________________________________________________________________________________________________________________ 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.

[boucadair]

Stu Said: We need ASAP, in some document, to fully specify, with normative language, in a manner enabling interoperability and satisfying the essential requirements enumerated in the requirements document, _an_ architecture for DRIP, or this whole DRIP exercise will have been a waste, as manufacturers will develop ASIC implementations of UAS RID as soon as ASTM ballots on the revision to F3411. Whether we immediately specify _the_ architecture for DRIP is of secondary importance. My previous assumption was that the -arch document would specify _the_ architecture. If that implies the architecture must somehow be specified in the -arch document without committing to HHITs, DNS, EPP and RDAP, then we need other documents (presumably starting with Bob's -uas-rid draft) that do commit to them, as otherwise we lack a specification showing how to meet the essential requirements in an interoperable way that leverages existing Internet standards, infrastructure and domain name registration business models, as per our charter. Further, -arch and any other documents needed to complete a usable specification should explicitly state how they satisfy specific numbered requirements from -reqs. No single standards track document needs to satisfy all those requirements, but every such document needs to be compatible with all those requirements, and each such document should show how to satisfy at least one of those requirements. Otherwise -reqs was a make-work exercise of no relevance.

…

On 6/28/2021 2:38 AM, ***@***.*** wrote: Shuai, This is a good comment from Daniel given that interoperating with other systems may break. I don’t think that changing must/could is appropriate here. Also, please note that “must” is not a normative language, but these listed in Section 2 are: == 2.  Conventions    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    "OPTIONAL" in this document are to be interpreted as described in BCP    14 [RFC2119] [RFC8174] when, and only when, they appear in all    capitals, as shown above. == This is not an IETF rule, but a rationale I’m following as an IETF contributor: If we are defining just **an** architecture for DRIP, then I would avoid using the normative language. If we are defining **the** DRIP architecture, it makes sense to use the normative language for clarity and spotting key aspects that are required for the architecture to be effective. If we decide to not use the normative language, then Section 2 should be removed. Cheers, Med *De :*Shuai Zhao ***@***.*** *Envoyé :* samedi 26 juin 2021 03:34 *À :* ietf-wg-drip/draft-ietf-drip-arch ***@***.***> *Cc :* BOUCADAIR Mohamed INNOV/NET ***@***.***>; Mention ***@***.***> *Objet :* Re: [ietf-wg-drip/draft-ietf-drip-arch] clarification section 4.1 (#20) @boucadair <https://github.com/boucadair> I dont think we have defined such documents/method to bind HHIT and X.509. @bob <https://github.com/bob> can clarify. per @evyncke <https://github.com/evyncke> suggestion, we should not use normative wording in the informational draft anyway. Can I propose to use "could be devised"? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXR6V6EVJDRFBSDLAFY6GDTUUVAFANCNFSM46H3YNNQ>.

----------------------------------------- Stuart W. Card, PhD, Principal Engineer AX Enterprize, LLC www.axenterprize.com 4947 Commercial Drive, Yorkville NY 13495

[mglt]

I Agree with med's comments.

[cardsw]

ASTM, FAA, NASA and USS developers have all committed to using X.509 in UTM, but X.509 won't fit in UAS RID, thus DRIP defines compact attestations that prove HHITs are in the registries they embed. Binding X.509 certs to DRIP attestations will at some point be necessary as UTM becomes real, but is not essential for pure UAS RID, the initial focus of the DRIP WG. A later DRIP doc can do.

[ShuaiZhao]

> Editor-note 8: is there a need to explain the how binding/proxy/translation between the HHIT and X509?

[mglt]

"""A later DRIP doc can do." I think we can remove this.

[ShuaiZhao]

comments from the mailing list that is not necessary to explain the how binding/proxy/translation between the HHIT and X509 since DRIP dont even have a solution on that topic yet.