[Drip] IPR Poll RE: Re: I-D Action: draft-ietf-drip-registries-21.txt

[[e-mail]]

Hi Authors,

Let me first wish you all a Happy New Year 2025.

We didn’t receive any reply to the following questions sent by Daniel. This input is needed for Daniel to complete the write-up. Please reply in a timely manner:

=
From the document shepherd I am asking each co-author to respond to the following questions:
12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? Have all required disclosures been filed? If
    not, explain why.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
==

Thank you.

Cheers,
Daniel & Med

De : Daniel Migault <[e-mail]>
Envoyé : lundi 23 décembre 2024 20:35
À : Robert Moskowitz <[e-mail]>
Cc : [e-mail]
Objet : [Drip] Re: I-D Action: draft-ietf-drip-registries-21.txt


Hi,

I do have some comments as well as some questions to proceed to the document shepherd.

* I assumed that RRsets have been implemented.Let me know if that is not correct.
* CDDL has been reviewed by Carsten. let me know if that is not correct.
* Nits provides
  ** Downref: Normative reference to an Informational RFC: RFC 9153

  ** Downref: Normative reference to an Informational RFC: RFC 9434

Please move them as informative, unless you really want to keep them as normative. I know we could justify this as these RFC needs to be read to fully understand the context of that document. However, I am not convinced we have to read them to implement / understand the current document. In my opinion informative is the right designation... but I can be flexible.

From the document shepherd I am asking each co-author to respond to the following questions:

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? Have all required disclosures been filed? If
    not, explain why.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.





Please find my comments below


1.2.  Use of Existing DNS Models

  ...

   It is not necessary, and in some case may not be desirable, for DRIP
   registrations to strictly follow this registrant-registrar-registry
   model.  Prevailing circumstances and/or local policy may mean some
   combination of these roles could be combined.  A DRIP registry might
   be operated by the CAA.

<mglt>needs to be expanded.</mglt>

  Or it could be outsourced to a DNS registry
   provider.  Registration policies - pricing, renewals, registrar and
   registrant agreements, etc. - will need to be developed.  These
   considerations should be determined by the CAA, perhaps in
   consultation with local stakeholders.  They are are out of scope for
   this document.

   The specifics for the UAS RID use case are detailed in the rest of
   document.

1.3.  Scope

   The scope of this document is limited to the 2001:30::/28 IPv6 prefix
   and its associated reverse domain in DNS.  The use case of DETs for
   UAS RID was the primary driver for the technology (and this
   document), as such requirements of other sectors or use cases are
   unknown at the time of publication.


   Other sectors may adopt this technology.  It is recommended that a
   global Apex (i.e.  IPv6 prefix) and international Apex manager be
   designated for each sector.

<mglt> I think the section is not accurate. It reflected the initial intention of being limited to the DNS delegation but it also contains a definition of RRsets. This makes it very UAS focused. I propose something like: The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of IPv6 Prefix, assigned by IANA for DETs 2001:30::/28 and RRsets used to handle DETs. </mglt>
4.  Public Information Registry
...

   DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed
   per convention) with at minimum an HHIT RRType.  Depending on local

<mglt>I am reading "at minimum" as HHIT RRtype MUST be present for DET. If that is correct, I see it as clearer especially as implementation can rely on its presence. I propose to use normative text here. </mglt>

...



   hhit-rr = [

       type: uint .size(2),

       abbreviation: tstr .size(15),

       registration-cert: bstr / #6.TBD

   ]



                      Figure 3: HHIT Wire Format CDDL

<mglt>It is probably time to have TBD done now </mglt>

6.2.1.  DRIP RAA Allocations

<mglt>Only a procedure for the 16376 - 16383 block is specified. I suggest that a template and a procedure is clearly provided when an allocation is requested. I am wondering if there are any volunteer for being an IANA expert. Of course these should not be mentioned in the document. </mglt>



6.2.2.  HHIT Entity Type

<mglt>Same here, please provide a template, a procedure for a code point request. I would prefer that the IANA registry does not not rely on drip-pki, so complete the RRset description, so the registry only reference this RFC and make drip-pki reference this draft instead. </mglt>






yours,

Daniel



On Fri, Dec 13, 2024 at 1:48 PM Robert Moskowitz <[e-mail]<mailto:[e-mail]>> wrote:
I have reviewed this version and the diffs from the prior version.

I agree with the changes made.


On 12/12/24 15:43, [e-mail]<mailto:[e-mail]> wrote:

Internet-Draft draft-ietf-drip-registries-21.txt is now available. It is a

work item of the Drone Remote ID Protocol (DRIP) WG of the IETF.



   Title:   DRIP Entity Tags (DET) in the Domain Name System (DNS)

   Authors: Adam Wiethuechter

            Jim Reid

   Name:    draft-ietf-drip-registries-21.txt

   Pages:   18

   Dates:   2024-12-12



Abstract:



   This document describes the discovery and management of DRIP Entity

   Tags (DETs) in DNS.  Authoritative Name Servers, with DRIP specific

   DNS structures and standard DNS methods, are the Public Information

   Registries for DETs and their related metadata.



The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-drip-registries/



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-drip-registries-21.html



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-drip-registries-21



Internet-Drafts are also available by rsync at:

rsync.ietf.org::internet-drafts





--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [e-mail]<mailto:[e-mail]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--
Tm-rid mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
Daniel Migault
Ericsson
____________________________________________________________________________________________________________
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.