Subject: [Drip] Normative language (RE: [ietf-wg-drip/draft-ietf-drip-arch] clarification section 4.1 (#20))

From: <[email-masked]>
Date: Mon, 28 Jun 2021 06:38:34 +0000

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 [mailto:[email-masked]]
Envoyé : samedi 26 juin 2021 03:34
À : ietf-wg-drip/draft-ietf-drip-arch <[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Mention <[email-masked]>
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<https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20#issuecomment-868914343>, 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.

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 28 Jun 2021 09:42:05 -0400

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, [email-masked] 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.
> 
> 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.
> 
> *De :*Shuai Zhao [mailto:[email-masked]]
> *Envoyé :* samedi 26 juin 2021 03:34
> *À :* ietf-wg-drip/draft-ietf-drip-arch 
> <[email-masked]>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 
> Mention <[email-masked]>
> *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"?
> 
> —
> Reply to this email directly, view it on GitHub 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20#issuecomment-868914343>, 
> 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