DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
draft-ietf-drip-rid-37
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
37 | Gunter Van de Velde | Request closed, assignment withdrawn: Sarah Banks Last Call OPSDIR review |
2024-01-26
|
37 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2023-03-13
|
37 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-02-27
|
37 | (System) | RFC Editor state changed to AUTH48 |
2023-02-26
|
37 | (System) | RFC Editor state changed to AUTH48 from EDIT |
2023-01-09
|
37 | (System) | RFC Editor state changed to EDIT from MISSREF |
2022-12-13
|
37 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-12-13
|
37 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-12-13
|
37 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-12-13
|
37 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-12-13
|
37 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-12-08
|
37 | (System) | IANA Action state changed to Waiting on Authors |
2022-12-05
|
37 | (System) | RFC Editor state changed to MISSREF |
2022-12-05
|
37 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-12-05
|
37 | (System) | Announcement was received by RFC Editor |
2022-12-02
|
37 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-12-02
|
37 | Amy Vezza | IESG has approved the document |
2022-12-02
|
37 | Amy Vezza | Closed "Approve" ballot |
2022-12-02
|
37 | Amy Vezza | Ballot approval text was generated |
2022-12-02
|
37 | Amy Vezza | Ballot writeup was changed |
2022-12-02
|
37 | Éric Vyncke | After several updates to address the non-blocking COMMENT + some late remarks by the AD (notably about the IPsec I-D being normative + representations of … After several updates to address the non-blocking COMMENT + some late remarks by the AD (notably about the IPsec I-D being normative + representations of RID in domain names). |
2022-12-02
|
37 | (System) | Removed all action holders (IESG state changed) |
2022-12-02
|
37 | Éric Vyncke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-12-02
|
37 | Robert Moskowitz | New version available: draft-ietf-drip-rid-37.txt |
2022-12-02
|
37 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-12-02
|
37 | Robert Moskowitz | Uploaded new revision |
2022-11-22
|
36 | Robert Moskowitz | New version available: draft-ietf-drip-rid-36.txt |
2022-11-22
|
36 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-11-22
|
36 | Robert Moskowitz | Uploaded new revision |
2022-11-15
|
35 | Robert Moskowitz | New version available: draft-ietf-drip-rid-35.txt |
2022-11-15
|
35 | (System) | New version approved |
2022-11-15
|
35 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2022-11-15
|
35 | Robert Moskowitz | Uploaded new revision |
2022-11-15
|
34 | Robert Moskowitz | New version available: draft-ietf-drip-rid-34.txt |
2022-11-15
|
34 | (System) | New version approved |
2022-11-15
|
34 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2022-11-15
|
34 | Robert Moskowitz | Uploaded new revision |
2022-10-14
|
33 | Robert Moskowitz | New version available: draft-ietf-drip-rid-33.txt |
2022-10-14
|
33 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-10-14
|
33 | Robert Moskowitz | Uploaded new revision |
2022-10-13
|
32 | Roman Danyliw | [Ballot comment] (Updated ballot) Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions. Thank for the revised … [Ballot comment] (Updated ballot) Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions. Thank for the revised text from -29 to -32. It addressed all of my DISCUSS and some of my COMMENT points. Further details with history below. These were DISCUSSes. From https://mailarchive.ietf.org/arch/msg/tm-rid/Of4ZUih3oiHvwZDrYG9cjBf27-Q/ >>> I’m having trouble following along on where the guidance for offline >>> verification is described – who exactly signs what with what key and >>> in what >>> format is this stored. Is this considered in-scope for this >>> document? Given >>> the asserted security properties, >> >> This guidance that lines up with 9.2 that the DET alone is not >> enough, go read drip-auth. But this is the core that makes drip-auth >> even possible. >> >>> -- I’ll note that draft-ietf-drip-auth is an informative reference. >> >> Yes. drip-rid does not, itself, need drip-auth. A trustworthy >> implementation would use drip-auth to provide full message trust, >> including of the messages providing the DET. > > Please see the recent addition to drip-auth, sec 1.1 >> >>> -- What exactly needs to be in the offline Observer’s cache? I >>> couldn’t find >>> that in draft-ietf-drip-auth. >> >> Well, then I need more updates to drip-auth! The cache, minimally is >> the HDA's DET and HI. 48 bytes worth per entry. As it says above: >> >> Only a small cache that contains the >> HDA's HI/HHIT and HDA meta-data is needed by the Observer. >> >> So the offline attestation in defined in drip-auth has the HDA's HHIT >> (DET). Use this to retrieve the HDA's HI. Use this HI to validate >> the signing of the registration attestation within the larger >> attestation. This does need to be clearly defined in drip-auth. I >> am making a note to check this out. > > This has recently been updated in drip-auth, sec 1.1 Adding the appropriate sub-section drip-auth reference would be helpful. It’s in a few places further into the document (not Section 1.1) These were DISCUSSes and https://mailarchive.ietf.org/arch/msg/tm-rid/aq-wsciitaB4h-CghTpPwDn1KuM/ >> ** Section 9. >> Therefore, the HHIT registration and HHIT/HI registration validation >> is strongly recommended. >> >> If validation isn’t done, who are the promised security guarantees of >> global >> non-collision possible? Practically, why isn’t this a MUST? > > I am open to it being a MUST, but I think I was advised to back off to > a strongly recommended. > > If not registered, no offline attestation available, only the > self-attestation. Understood. Thanks for explaining. I recommend added this explanation into the text to justify why the MUST isn’t needed. >> ** Section 9.5. >> >> The UAS/USS registration >> process should include registering the DET and MUST reject a >> collision, forcing the UAS to generate a new HI and thus HHIT and >> reapplying to the DET registration process. >> >> How does a UAS “generate a new HI” in the case of a CTA2063A or >> manufacturer >> hard-coding the HHIT per Section 3.2 of draft-ietf-drip-arch-24? > > See drip-registries. That is covered there, and it parallels ANIMA in > many ways. The CTA encoded HHIT is a permanent DET to bootstrap > registration of one or lots of operational (Session) DETs. Strongly recommend putting into reference to relevant section in drip-registries. From https://mailarchive.ietf.org/arch/msg/tm-rid/DGQ5pQ-TNkzG-WDoHoOnTVoA-so/: > > ** Section 4. > > The original UAS ID Types 1 - 3 allow for an UAS ID with a maximum > > length of 20 bytes, this new SSI (Type 4) uses the first byte of the > > ID for the SSI Type, thus restricting the UAS ID of this type to a > > maximum of 19 bytes. The SSI Types initially assigned are : > > > > ID 1 IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID. > > > > ID 2 3GPP - IEEE 1609.2-2016 HashedID8 > > > > -- Is this text saying that the HHITs format defined in this text can be used > with a UAS ID Type = 1, 2, 3? >No, at one time I had the full UAS ID Type table here and I was asked to > cut it: > > ASTM Standard Specification for Remote ID and Tracking [F3411-19] > specifies three UAS ID types: > > TYPE-1 A static, manufacturer assigned, hardware serial number per > ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" > [CTA2063A]. > > TYPE-2 A CAA assigned (presumably static) ID. > > TYPE-3 A UTM system assigned UUID [RFC4122]. These can be dynamic, > but do not need to be. > > Only the new Type-4, Session ID can support HHITs. Well your type-1 CTA > SN COULD be an encoded HHIT. > Do you feel that this information should be added or text saying that > HHIT is only used in type-4? I would probably err on the side of saying less and make clear that only type-4 is relevant to HHIT. > ** Section 4.2. Please provide a normative reference for Base32. RFC4648? > We have had this discussion. The CTA alphabet selection precludes > referencing ANYthing I have found out there. We MUST work with the > letters and numbers they allow and it DOES NOT map to 4648. We had this > discussion during early reviews. I leave this to WG and the AD. We should technically have a citation on how to compute this Base32 variant if it isn’t the expected on RFC4648. |
2022-10-13
|
32 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2022-08-18
|
32 | Paul Wouters | [Ballot comment] OLD DISCUSSES: #1 Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all … [Ballot comment] OLD DISCUSSES: #1 Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications. Regardless of what zone is used, someone needs to keep it operational. It might be an attractive target to attack, eg to try and avoid drones being shut down. I would feel much better if this zone was optional, not mandatory. (but if optional, one could also argue maybe not have it at all?) If the HHITs cannot be looked up with services provided by the registrar identified via the embedded hierarchical information or its registration validated by registration attestations messages [drip-authentication], then the HHIT is either fraudulent or revoked/expired. That's quite catastrophic if there is a Registrar/Registry outage. Would all the drones get shot down or would they all be ignored (so they can fly to their terrorism target) #2 As DISCUSS'ED by others, https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm does not seem to have a third field for "status" to denotate RECOMMENDED, REQUIRED, etc, even though RFC 7401 creates the registry, uses the terms too but doesn't populate a status field. Perhaps this or another short RFC could do so. Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry calls it "Algorithm Profile" (singular) and "Value" (singular) #3 Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the slash and pipe symbols on those first and second lines got swapped by accident? #4 The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding: Value Description TBD2 (suggested value 4) An EdDSA key is present, in the format defined in [RFC8080] I have asked the Expert of this Registry whether they are okay with this entry to the ipseckey-rr-parameters registry. It might be confusing for IKE. COMMENTS: #1 100.hhit.arpa IN PTR raa.example.com. Please add a trailing dot, eg "100.hhit.arpa." Similarly for: 100.50.det.uas.icao.int IN PTR foo.uss.icao.int. #2 HIP DNS RR (Resource Record) Add reference to RFC5205 on its first mention. #3 However, this document does not intend to provide a recommendation. weasel wording. It should probaby just state "this document does not provide a recommendation." #4 The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. This can be achieved with online signing. I would remove this speculative sentence unless it is backed by some real numbers. |
2022-08-18
|
32 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss |
2022-08-03
|
32 | Robert Moskowitz | New version available: draft-ietf-drip-rid-32.txt |
2022-08-03
|
32 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-08-03
|
32 | Robert Moskowitz | Uploaded new revision |
2022-07-25
|
31 | Robert Moskowitz | New version available: draft-ietf-drip-rid-31.txt |
2022-07-25
|
31 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-07-25
|
31 | Robert Moskowitz | Uploaded new revision |
2022-07-21
|
30 | Mohamed Boucadair | Added to session: IETF-114: drip Mon-1330 |
2022-07-14
|
30 | Warren Kumari | [Ballot comment] I'm clearing my DISCUSS because my points were addressed, but I am still concerned by the issue in Comment 2 -- just because … [Ballot comment] I'm clearing my DISCUSS because my points were addressed, but I am still concerned by the issue in Comment 2 -- just because you *can* put stuff in the DNS, doesn't mean that you *should*. The DNS is a loosely coherent, scalable, distributed database with good performance and deployment -- but that doesn't mean that it should be overloaded to store $whatever - there is a complexity, scalability and monetary cost to running the system; it isn't a free, infinitely scalable resource, and we quickly get into a "tragedy of the commons" problem. I have a few comments and questions related to this document: 1: "Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28)." This seems like a *really* large block of addresses to be taking and using for this purpose - I understand that there is already some concern about the number of address bits being used for the crypto parts, but it does seem incredibly wasteful to be deciding to use this much of the IPv6 Special Purpose block for this -- there are only 32 /28s in the /23. Yes, IPv6 is large, but "no-one will need more that 640k of RAM", IPv4 was originally viewed as massive, etc --- this is 1,267,650,600,228,229,401,496,703,205,376 host addresses. 2: I have some reservations about how much this punts a large amount of work to the DNS -- "Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications.", etc. Has there been discussion with the DNSOP WG about the potential load profile? And with the IAB about having an entry under .arpa for this? This does feel somewhat like the well known "just put it in the DNS"-type solution (see slide 13 here). Yes, the DNS is an incredibly good, well scaling solution, but there are costs, and I think that more investigation into how this gets used without just shifting costs to someone else is needed. This is repeated in things like "A DET reverse lookup could be to: a69e.ad0.1952.a3ad.1405.280.30.2001.20.10.det.arpa. or: a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int." - yes, it *could* be, but this feels like it is assuming that .arpa or .icao.int is happy to serve this function, have the registry, etc. |
2022-07-14
|
30 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2022-07-13
|
30 | Murray Kucherawy | [Ballot comment] Thanks for resolving my IANA Considerations concerns. Rather than repeating them, I support Paul's and John's DISCUSS positions. I like that we're recycling … [Ballot comment] Thanks for resolving my IANA Considerations concerns. Rather than repeating them, I support Paul's and John's DISCUSS positions. I like that we're recycling existing IETF technologies to map to a new purpose like this. However, like Warren (who did not DISCUSS it or I would support that too), I'd like to hear about what consultation was done with DNSOP, if any. I have the same question about REGEXT for the EPP references. Section 3.3.1 says: [...] An RAA MUST provide a set of services to allocate HDAs to organizations. Are we talking about online services of some kind? If so, which ones? If not, is this an appropriate use of BCP 14? Sections 8.3 and 8.5 should be explicit that the Reference for the new entry is this document. Even though that's obvious, the instructions should be complete. (Note, for example, that they're correctly different in Section 8.4.) |
2022-07-13
|
30 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2022-07-11
|
30 | John Scudder | [Ballot comment] Thanks for addressing my discuss point and comments. I've pasted the previous discuss point below, for posterity. Previous discuss: 1. In §3.2, … [Ballot comment] Thanks for addressing my discuss point and comments. I've pasted the previous discuss point below, for posterity. Previous discuss: 1. In §3.2, The following HHIT Suite IDs are defined: HHIT Suite Value RESERVED 0 RSA,DSA/SHA-256 1 [RFC7401] ECDSA/SHA-384 2 [RFC7401] ECDSA_LOW/SHA-1 3 [RFC7401] EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED) What, exactly, does the notation "RECOMMENDED" on the last quoted line mean? AFAICT there's no unambiguous way to parse this. My guess is that it's meant to mean "this is the suite we think you should use". Whatever the intended meaning, please elaborate to make the meaning clear. I suggest removing the notation from the table, and providing prose in some appropriate section instead, with "RECOMMENDED" if you think the RFC 2119 keyword is needed. If desired, you could xref that section from the table, although I don't think that's really necessary. This comment also applies to the similar lines in §3.4.1, §3.4.1.1, and §3.4.2. The use in §3.4.1.1 is especially confounding, since the prose right before the table tells us that (all of) "the following EdDSA curves are required" (but evidently not REQUIRED)... but only some of the required curves are RECOMMENDED? I definitely have no clue, then, what "RECOMMENDED" means in this section. RFC 2119 basically defines RECOMMENDED as a weaker form of REQUIRED, but that doesn't seem to be how you're using it. Similarly, I have no clue what "RECOMMENDED" is meant to mean in its several uses in §8.2 and §8.4. I suggest simply removing it from those sections entirely. (Taken together, this comment covers every use of RECCOMMENDED in the document.) Comments: 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken in considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-07-11
|
30 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2022-07-11
|
30 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-07-11
|
30 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-07-11
|
30 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-07-11
|
30 | Robert Moskowitz | New version available: draft-ietf-drip-rid-30.txt |
2022-07-11
|
30 | (System) | New version approved |
2022-07-11
|
30 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2022-07-11
|
30 | Robert Moskowitz | Uploaded new revision |
2022-06-30
|
29 | Murray Kucherawy | [Ballot discuss] John raised this in a comment, and I agree with it: Please provide proper guidance for your new registry's designated experts, or let's … [Ballot discuss] John raised this in a comment, and I agree with it: Please provide proper guidance for your new registry's designated experts, or let's discuss why you think what's there is sufficient. |
2022-06-30
|
29 | Murray Kucherawy | [Ballot comment] Rather than repeating them, I support Paul's and John's DISCUSS positions. I like that we're recycling existing IETF technologies to map to a … [Ballot comment] Rather than repeating them, I support Paul's and John's DISCUSS positions. I like that we're recycling existing IETF technologies to map to a new purpose like this. However, like Warren (who did not DISCUSS it or I would support that too), I'd like to hear about what consultation was done with DNSOP, if any. I have the same question about REGEXT for the EPP references. Section 3.3.1 says: [...] An RAA MUST provide a set of services to allocate HDAs to organizations. Are we talking about online services of some kind? If so, which ones? If not, is this an appropriate use of BCP 14? Sections 8.3 and 8.5 should be explicit that the Reference for the new entry is this document. Even though that's obvious, the instructions should be complete. (Note, for example, that they're correctly different in Section 8.4.) |
2022-06-30
|
29 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to Discuss from No Record |
2022-06-30
|
29 | (System) | Changed action holders to Éric Vyncke, Andrei Gurtov, Robert Moskowitz, Stuart Card, Adam Wiethuechter (IESG state changed) |
2022-06-30
|
29 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-06-30
|
29 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-06-30
|
29 | Andrew Alston | [Ballot comment] Thanks for the document, After reading the document I went through the other discuss points and they covered pretty much everything I had … [Ballot comment] Thanks for the document, After reading the document I went through the other discuss points and they covered pretty much everything I had come up with and hence I support the other discusses, but with specific emphasis on Paul's discuss, as regards to making that zone mandatory and the failure situation that results. |
2022-06-30
|
29 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2022-06-30
|
29 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-06-30
|
29 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2022-06-30
|
29 | Murray Kucherawy | [Ballot comment] [NOTE: This ballot is not yet complete. I'm traveling and will submit an update ASAP.] John raised this in a comment, and I … [Ballot comment] [NOTE: This ballot is not yet complete. I'm traveling and will submit an update ASAP.] John raised this in a comment, and I agree with it: You need to provide proper guidance for your new registry's designated experts. |
2022-06-30
|
29 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2022-06-29
|
29 | Paul Wouters | [Ballot discuss] #1 Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications. … [Ballot discuss] #1 Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications. Regardless of what zone is used, someone needs to keep it operational. It might be an attractive target to attack, eg to try and avoid drones being shut down. I would feel much better if this zone was optional, not mandatory. (but if optional, one could also argue maybe not have it at all?) If the HHITs cannot be looked up with services provided by the registrar identified via the embedded hierarchical information or its registration validated by registration attestations messages [drip-authentication], then the HHIT is either fraudulent or revoked/expired. That's quite catastrophic if there is a Registrar/Registry outage. Would all the drones get shot down or would they all be ignored (so they can fly to their terrorism target) #2 As DISCUSS'ED by others, https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm does not seem to have a third field for "status" to denotate RECOMMENDED, REQUIRED, etc, even though RFC 7401 creates the registry, uses the terms too but doesn't populate a status field. Perhaps this or another short RFC could do so. Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry calls it "Algorithm Profile" (singular) and "Value" (singular) #3 Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the slash and pipe symbols on those first and second lines got swapped by accident? #4 The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding: Value Description TBD2 (suggested value 4) An EdDSA key is present, in the format defined in [RFC8080] I have asked the Expert of this Registry whether they are okay with this entry to the ipseckey-rr-parameters registry. It might be confusing for IKE. |
2022-06-29
|
29 | Paul Wouters | [Ballot comment] #1 100.hhit.arpa IN PTR raa.example.com. Please add a trailing dot, eg "100.hhit.arpa." Similarly for: … [Ballot comment] #1 100.hhit.arpa IN PTR raa.example.com. Please add a trailing dot, eg "100.hhit.arpa." Similarly for: 100.50.det.uas.icao.int IN PTR foo.uss.icao.int. #2 HIP DNS RR (Resource Record) Add reference to RFC5205 on its first mention. #3 However, this document does not intend to provide a recommendation. weasel wording. It should probaby just state "this document does not provide a recommendation." #4 The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. This can be achieved with online signing. I would remove this speculative sentence unless it is backed by some real numbers. |
2022-06-29
|
29 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2022-06-29
|
29 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-06-29
|
29 | John Scudder | [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long … [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken in considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-06-29
|
29 | John Scudder | Ballot comment text updated for John Scudder |
2022-06-29
|
29 | John Scudder | [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long … [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-06-29
|
29 | John Scudder | Ballot comment text updated for John Scudder |
2022-06-29
|
29 | John Scudder | [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long … [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-06-29
|
29 | John Scudder | Ballot comment text updated for John Scudder |
2022-06-29
|
29 | John Scudder | [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long … [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-06-29
|
29 | John Scudder | Ballot comment text updated for John Scudder |
2022-06-29
|
29 | John Scudder | [Ballot discuss] 1. In §3.2, The following HHIT Suite IDs are defined: HHIT Suite Value … [Ballot discuss] 1. In §3.2, The following HHIT Suite IDs are defined: HHIT Suite Value RESERVED 0 RSA,DSA/SHA-256 1 [RFC7401] ECDSA/SHA-384 2 [RFC7401] ECDSA_LOW/SHA-1 3 [RFC7401] EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED) What, exactly, does the notation "RECOMMENDED" on the last quoted line mean? AFAICT there's no unambiguous way to parse this. My guess is that it's meant to mean "this is the suite we think you should use". Whatever the intended meaning, please elaborate to make the meaning clear. I suggest removing the notation from the table, and providing prose in some appropriate section instead, with "RECOMMENDED" if you think the RFC 2119 keyword is needed. If desired, you could xref that section from the table, although I don't think that's really necessary. This comment also applies to the similar lines in §3.4.1, §3.4.1.1, and §3.4.2. The use in §3.4.1.1 is especially confounding, since the prose right before the table tells us that (all of) "the following EdDSA curves are required" (but evidently not REQUIRED)... but only some of the required curves are RECOMMENDED? I definitely have no clue, then, what "RECOMMENDED" means in this section. RFC 2119 basically defines RECOMMENDED as a weaker form of REQUIRED, but that doesn't seem to be how you're using it. Similarly, I have no clue what "RECOMMENDED" is meant to mean in its several uses in §8.2 and §8.4. I suggest simply removing it from those sections entirely. (Taken together, this comment covers every use of RECCOMMENDED in the document.) |
2022-06-29
|
29 | John Scudder | [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long … [Ballot comment] 2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section. 3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document? 4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set. I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.) 5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2, Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN The flow would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII? 6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?) 7. Similarly, for capitalized "Pilot" in §6. 8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there. NITS: 9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate. 10. In §3.5.1, Care must be considering the size of the hash portion Something's missing here. Perhaps "Care must be taken considering..."? 11. In §4.2, Definition of this mapping service is currently out of scope of this document. I think you can drop "currently" considering you're going to press as an RFC. |
2022-06-29
|
29 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2022-06-29
|
29 | Warren Kumari | [Ballot discuss] Apologies for the terse / rushed tone of this ballot - I'm currently traveling and really short on time. 1: "A mapping service … [Ballot discuss] Apologies for the terse / rushed tone of this ballot - I'm currently traveling and really short on time. 1: "A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to high-order 58 bits (Prefix | HID) of the HHIT. Definition of this mapping service is currently out of scope of this document." -- this feels really underspecified, especially because it is a MUST. DNSSEC provides channel security, but by itself doesn't provide "trusted" data, nor provide a "conversion", etc. Where is the "trust" here? (Sec 9 doesn't really answer this) Who is supposed to run this? Even more so, why is this a "just stick it in the DNS" type solution (see comment #2). 2: "Now it should be noted that the 2^64 attempts is for stealing a specific HHIT. Consider a scenario of a street photography company with 1,024 UAs (each with its own HHIT); you'd be happy stealing any one of them." This is only true if I want to steal one for this specific street photography company - surely I'd be perfectly happy "stealing" any HHIT that works? Doesn't that make it more on the order of (number of units), not 1024? Also, the "Therefore, the HHIT registration and HHIT/HI registration validation is strongly recommended." bit seems underspecified. |
2022-06-29
|
29 | Warren Kumari | [Ballot comment] Apologies for the terse review (and terse tone) -- I'm currently traveling and short on time. I have a few comments and questions … [Ballot comment] Apologies for the terse review (and terse tone) -- I'm currently traveling and short on time. I have a few comments and questions related to this document: 1: "Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28)." This seems like a *really* large block of addresses to be taking and using for this purpose - I understand that there is already some concern about the number of address bits being used for the crypto parts, but it does seem incredibly wasteful to be deciding to use this much of the IPv6 Special Purpose block for this -- there are only 32 /28s in the /23. Yes, IPv6 is large, but "no-one will need more that 640k of RAM", IPv4 was originally viewed as massive, etc --- this is 1,267,650,600,228,229,401,496,703,205,376 host addresses. 2: I have some reservations about how much this punts a large amount of work to the DNS -- "Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications.", etc. Has there been discussion with the DNSOP WG about the potential load profile? And with the IAB about having an entry under .arpa for this? This does feel somewhat like the well known "just put it in the DNS"-type solution (see slide 13 here). Yes, the DNS is an incredibly good, well scaling solution, but there are costs, and I think that more investigation into how this gets used without just shifting costs to someone else is needed. This is repeated in things like "A DET reverse lookup could be to: a69e.ad0.1952.a3ad.1405.280.30.2001.20.10.det.arpa. or: a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int." - yes, it *could* be, but this feels like it is assuming that .arpa or .icao.int is happy to serve this function, have the registry, etc. |
2022-06-29
|
29 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2022-06-29
|
29 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. I have following comments/observations, which I believe will improve this specification if addressed. - Section 1: says … [Ballot comment] Thanks for working on this specification. I have following comments/observations, which I believe will improve this specification if addressed. - Section 1: says - This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP. this actually puts me off, how does a DRIP implementation use HHIT without using RFC7401 when this is all about extending and updating 7401? what are the other options the DRIP implementation can use instead of this? if there are any why do we need this specification? I simply can't understand the claims here. - I noted that there is downref to 8032, was this indicated in the last call announcement? - Section 8.2 is shy of giving proper guidance for "Expert review". It points to Section 4.5 of RFC8126 and that section says - The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request. I didn't find any such description. - I also noted that there is lack of discussion on HHIT registration and validation technique. For this I am supporting Romans Discuss point of HHIT registration and validation. |
2022-06-29
|
29 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
2022-06-29
|
29 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. I have following comments/observations, which I believe will improve this specification if addressed. - Section 1: says … [Ballot comment] Thanks for working on this specification. I have following comments/observations, which I believe will improve this specification if addressed. - Section 1: says - This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP. this actually puts me off, how does a DRIP implementation use HHIT without using RFC7401 when this is all about extending and updating 7401? what are the other options the DRIP implementation can use instead of this? if there are any why do we need this specification? I simply can't understand the claims here. - I noted that there is downref to 8032, was this indicated in the last call announcement? - Section 8.2 is shy of giving proper guidance for "Expert review". It points to Section 4.5 of RFC8126 and that section says - The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request. I didn't any such description. - I also noted that there is lack of discussion on HHIT registration and validation technique. For this I am supporting Romans Discuss point of HHIT registration and validation. |
2022-06-29
|
29 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-06-29
|
29 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-06-29
|
29 | Robert Moskowitz | New version available: draft-ietf-drip-rid-29.txt |
2022-06-29
|
29 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-06-29
|
29 | Robert Moskowitz | Uploaded new revision |
2022-06-28
|
28 | Roman Danyliw | [Ballot discuss] ** With updates tag for RFC7343, I read the text in Section 3.5.* as providing a generic description of a new ORCHID … [Ballot discuss] ** With updates tag for RFC7343, I read the text in Section 3.5.* as providing a generic description of a new ORCHID computation techniques. Other parts of the text describe how to use it for HIT and HHIT. If that interpretation is correct: -- Section 3.5.1. With a 28-bit IPv6 prefix, the remaining 100 bits can be divided in any manner between the additional information ("Info"), OGA ID, and the hash output. Since this section is describing a generic ORCHID technique, does this mean one could potentially choose a 0 or 1 bit hash output size? All the provided security analysis is predicated on a 64-bit HIT. What is associated analysis and security considerations for smaller HITs? -- Section 3.5.1. The header content consists of the Prefix, the Additional Information ("Info"), and OGA ID (HIT Suite ID). Secondly, the length of the resulting hash is set by sum of the length of the ORCHID header fields. The second sentence is true only if ORCHID setup is according to the DRIP spec: p=28, info=28, OGA-ID=8 to make 64 bits. However, this is a generic update to define an ORCHID. The previous text said that an OGA-ID could be 4 bits – 28+28+4 = 60, so if the “resulting hash should be set by the length of the ORCHID header field”, it would be off by 4 bits. ** Section 4.2 A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to high-order 58 bits (Prefix | HID) of the HHIT. Can this “trust” be described in more detail? Section 4.4 makes it a point to say “cryptographically bind all content in the ORCHID through the hashing function. A recipient of a DET that has the underlying HI can directly trust and act on all content in the HHIT”. Here this information is being split. Is the out-of-scope mechanism expected to provide a similar guarantee? ** Section 4.6 The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an 84-byte self-proof attestation (timestamp, HHIT, and signature of these) to provide proof of Remote ID ownership (GEN-1 in [RFC9153]). In practice, the Wrapper and Manifest authentication formats (Sections 6.3.3 and 6.3.4 of [drip-authentication]) implicitly provide this self-attestation. A lookup service like DNS can provide the HI and registration proof (GEN-3 in [RFC9153]). Similarly, for Observers without Internet access, a 200-byte offline self-attestation could provide the same Remote ID ownership proof. This attestation would contain the HDA's signing of the UA's HHIT, itself signed by the UA's HI. Only a small cache that contains the HDA's HI/HHIT and HDA meta-data is needed by the Observer. However, such an object would just fit in the ASTM Authentication Message (Section 2.2 of [RFC9153]) with no room for growth. In practice, [drip-authentication] provides this offline self-attestation in two authentication messages: the HDA's certification of the UA's HHIT registration in a Link authentication message whose hash is sent in a Manifest authentication message. I’m having trouble following along on where the guidance for offline verification is described – who exactly signs what with what key and in what format is this stored. Is this considered in-scope for this document? Given the asserted security properties, -- I’ll note that draft-ietf-drip-auth is an informative reference. -- What exactly needs to be in the offline Observer’s cache? I couldn’t find that in draft-ietf-drip-auth. -- Why is the first sentence in the first paragraph present? It is describing a hypothetical situation that isn’t used in DRIP. Likewise, the first sentence of the second paragraph also seems like a hypothetical using verbs like “could provide” -- The text reference a lookup service, how does that service an offline Observer? ** Section 9. Therefore, the HHIT registration and HHIT/HI registration validation is strongly recommended. If validation isn’t done, who are the promised security guarantees of global non-collision possible? Practically, why isn’t this a MUST? ** Section 9.5. The UAS/USS registration process should include registering the DET and MUST reject a collision, forcing the UAS to generate a new HI and thus HHIT and reapplying to the DET registration process. How does a UAS “generate a new HI” in the case of a CTA2063A or manufacturer hard-coding the HHIT per Section 3.2 of draft-ietf-drip-arch-24? |
2022-06-28
|
28 | Roman Danyliw | [Ballot comment] Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions. ** Section 3.3.1. Please provide a … [Ballot comment] Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions. ** Section 3.3.1. Please provide a reference for HIP RVS (RFC8004) and make it a normative reference. ** Section 3.3.1. Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications. Thus further thought will be needed in the actual zone tree and registration process [drip-registries]. This won’t age well. Either we know the approach for the zone, or the text isn’t included. This is a proposed standard status document, not one that is experimental. ** Section 3.5.*. What is means by this document updating RFC7343: -- Section 3.5: This should be viewed as an update to ORCHIDv2 [RFC7343], as it can produce ORCHIDv2 output. -- Section 3.5.1: The new ORCHID function is as follows: … Can the text clarify in what way this is intended to be read by the reader – is this new ORCHID function replacing the current ORCHIDv2 generation technique, providing a second way to make an ORCHIDv2 identifier, making an “ORCHIDv2.1”? ** Section 3.5.1. Proposed clarification: OLD p + n + o + m = 128 bits NEW (or something like that) Sizeof(p + n + o + m) 128 bits ** Section 4. The original UAS ID Types 1 - 3 allow for an UAS ID with a maximum length of 20 bytes, this new SSI (Type 4) uses the first byte of the ID for the SSI Type, thus restricting the UAS ID of this type to a maximum of 19 bytes. The SSI Types initially assigned are : ID 1 IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID. ID 2 3GPP - IEEE 1609.2-2016 HashedID8 -- Is this text saying that the HHITs format defined in this text can be used with a UAS ID Type = 1, 2, 3? -- Why is it germane to talk about 3GPP as a UAS ID Types. Wouldn’t it be more precise to say something to the effect of “when a SSI Type=4, the first byte of the UAS ID is set to 1 when a DET is used”? ** Section 4.2. Please provide a normative reference for Base32. RFC4648? ** Section 4.2. Please provide a reference of “Authentication Messages”. ** Section 4.5. A registration process, [drip-registries], ensures DET global uniqueness (ID-4 in [RFC9153]). Given Section 4.2, aren’t the out-of-scope mapping process also required in certain circumstances? ** Section 5. There are two approaches for storing and retrieving DETs using DNS. Can the text more clearly explain who is retrieving the DETs. ** Section 5. The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response. -- What is the actionable guidance from this text? The second sentence says HDA SHOULD provide a DNS service. Is the first sentence saying that using DNSSEC won’t scale? What is the impact of not using DNSEC? -- How will revocation be handled if the HAD doesn’t provide a DNS service? ** Section 9.0 A Python scrip t is available to randomly generate 1M HHITs that did not produce a hash collision which is a simpler attack than a first or second pre-image attack. -- Per “A Python script is available …”, where is it available? -- Why is producing a 1M HHIT list sufficient to motivate a reduced risk in second pre-image attack? What's the "magic" of 1M? ** Section 9.0 As such, use of DNSSEC by the DET registries is recommended to provide trust in HI retrieval. Didn’t Section 5 say “The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone” acknowledge that DNSSEC won’t scale or perform. If that’s the case, this is an odd recommendation. ** Section 9.4 That is, the MAC address should be stable for at least a UA operation. Where is the definition which time bounds “UA operation”? ** Section 9.5 The 64-bit hash size does have an increased risk of collisions over the 96-bit hash size used for the other HIT Suites Is it “over … other HIT Suites” or when ORCHIDv2 is used to construct a HIT? |
2022-06-28
|
28 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2022-06-26
|
28 | Erik Kline | [Ballot comment] # Internet AD comments for {draft-ietf-drip-rid-28} CC @ekline ## Comments ### S3.5.1 * "Care must be considering the size" doesn't quite … [Ballot comment] # Internet AD comments for {draft-ietf-drip-rid-28} CC @ekline ## Comments ### S3.5.1 * "Care must be considering the size" doesn't quite read correctly to me. "Consideration must be given to the size of the hash portion..."? * This whole final paragraph I find a bit obscure. Especially since mentally I'm comparing it to layout depicted in Figure 1. Is "(n)" where the RAA and HDA bits get encoded? I assume that's what's meant by the reference to "28 bits" at the end. I think just being a bit more explicit should suffice to make it that much easier to follow. ## Nits ### S9 * "you'd be happy" -> "an attacker may well be satisfied" Consider changing all 2nd person usages to 3rd person. |
2022-06-26
|
28 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-06-22
|
28 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-06-13
|
28 | Éric Vyncke | Placed on agenda for telechat - 2022-06-30 |
2022-06-13
|
28 | Éric Vyncke | Ballot has been issued |
2022-06-13
|
28 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2022-06-13
|
28 | Éric Vyncke | Created "Approve" ballot |
2022-06-13
|
28 | Éric Vyncke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2022-05-30
|
28 | Éric Vyncke | RID is ready for IESG ballot but waiting for ARCH I-D to ballot both of them at the same IESG telechat. |
2022-05-24
|
28 | Éric Vyncke | Ballot writeup was changed |
2022-05-17
|
28 | Robert Moskowitz | New version available: draft-ietf-drip-rid-28.txt |
2022-05-17
|
28 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-05-17
|
28 | Robert Moskowitz | Uploaded new revision |
2022-05-16
|
27 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-05-16
|
27 | Robert Moskowitz | New version available: draft-ietf-drip-rid-27.txt |
2022-05-16
|
27 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-05-16
|
27 | Robert Moskowitz | Uploaded new revision |
2022-05-16
|
26 | Pascal Thubert | Request for Last Call review by INTDIR Completed: Ready with Nits. Reviewer: Pascal Thubert. Sent review to list. |
2022-05-13
|
26 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-05-13
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2022-05-13
|
26 | Robert Moskowitz | New version available: draft-ietf-drip-rid-26.txt |
2022-05-13
|
26 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-05-13
|
26 | Robert Moskowitz | Uploaded new revision |
2022-05-12
|
25 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2022-05-12
|
25 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-drip-rid-25. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-drip-rid-25. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. We understand that, upon approval of this document, there are eight actions which we must complete. First, in the IANA IPv6 Special-Purpose Address Registry located at: https://www.iana.org/assignments/iana-ipv6-special-registry a new registration is to be made as follows: Address Block: TBD (suggested: 2001:30::/28) Name: DRIP Entity Tags (DETs) Prefix RFC: [ RFC-to-be ] Allocation Date: TBD Termination Date: N/A Source: False Destination: False Globally Reachable: False Reserved-by-Protocol: False Second, a new registry page will be created called the Drone Remote ID Protocol. The Hierarchical HIT (HHIT) Prefixes registry will be created on the Drone Remote ID Protocol registry page. The registration procedure for the registry will be Expert Review as defined in RFC8126. There is an initial registration in the new registry as follows: HHIT Use: DET Bits: 28 Value: TBD (suggested: 2001:30::/28) Reference: [ RFC-to-be ] Third, a new registry will be created called the Hierarchical HIT (HHIT) Suite ID registry also on the Drone Remote ID Protocol registry page. The registration procedure for the registry will be IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows: HHIT Suite Value Reference RESERVED 0 [ RFC-to-be ] RSA,DSA/SHA-256 1 [RFC7401] ECDSA/SHA-384 2 [RFC7401] ECDSA_LOW/SHA-1 3 [RFC7401] EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED) [ RFC-to-be ] HDA Private Use 1 TBD4 (suggested value 254) [ RFC-to-be ] HDA Private Use 2 TBD5 (suggested value 255) [ RFC-to-be ] Fourth, in the CGA Extension Type Tags registry on the Cryptographically Generated Addresses (CGA) Message Type Name Space registry page located at: https://www.iana.org/assignments/cga-message-types a new registration will be made as follows: CGA Type Tag: 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 Reference: [ RFC-to-be ] In addition, we will also list this document as an additional reference for the CGA Extension Type Tags registry. Fifth, in the HI Algorithm registry on the Host Identity Protocol (HIP) Parameters registry page located at: https://www.iana.org/assignments/hip-parameters a new registration will be made as follows: Value: TDB Algorithm Profile: EdDSA Reference: [RFC8032][ RFC-to-be ] IANA notes that the authors suggest a value 13 for this registration. Sixth, a new subregistry will be created called the EdDSA Curve Label on the Host Identity Protocol (HIP) Parameters registry page located at: https://www.iana.org/assignments/hip-parameters There are initial registrations in the subregistry as follows: Algorithm Curve Values Reference EdDSA RESERVED 0 [ RFC-to-be ] EdDSA EdDSA25519 1 [RFC8032] EdDSA EdDSA25519ph 2 [RFC8032] EdDSA EdDSA448 3 [RFC8032] EdDSA EdDSA448ph 4 [RFC8032] Unassigned 5-65535 IANA Question: What is the registration procedure for this new subregistry? Seventh, in the HIT Suite ID registry on the Host Identity Protocol (HIP) Parameters registry page located at: https://www.iana.org/assignments/hip-parameters a new registration will be made as follows: Value: TBD Suite ID: EdDSA/cSHAKE128 Reference: [ RFC-to-be ] IANA notes that the authors suggest a value 5 for this registration. Eighth, in the Algorithm Type Field registry on the IPSECKEY Resource Record Parameters registry page located at: https://www.iana.org/assignments/ipseckey-rr-parameters a new registration will be made as follows: Value: TBD Description: An EdDSA key is present, in the format defined in [RFC8080] Reference: [ RFC-to-be ] IANA notes that the authors suggest a value 4 for this registration. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2022-05-12
|
25 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-05-12
|
25 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-05-12
|
25 | Robert Moskowitz | New version available: draft-ietf-drip-rid-25.txt |
2022-05-12
|
25 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-05-12
|
25 | Robert Moskowitz | Uploaded new revision |
2022-05-11
|
24 | Éric Vyncke | A revised I-D is needed to address the IOT directorate and Gen ART Last Call reviews. It would be nice to move the -arch and … A revised I-D is needed to address the IOT directorate and Gen ART Last Call reviews. It would be nice to move the -arch and the -rid together from now on. Good job by the authors (including fast replies to the reviews). Regards, -éric |
2022-05-11
|
24 | (System) | Changed action holders to Éric Vyncke, Andrei Gurtov, Robert Moskowitz, Stuart Card, Adam Wiethuechter (IESG state changed) |
2022-05-11
|
24 | Éric Vyncke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2022-05-11
|
24 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2022-05-10
|
24 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
2022-05-05
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2022-05-05
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2022-05-04
|
24 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Pascal Thubert |
2022-05-04
|
24 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Pascal Thubert |
2022-05-04
|
24 | Brian Haberman | Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Brian Haberman. Sent review to list. |
2022-04-28
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2022-04-28
|
24 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2022-04-27
|
24 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Brian Haberman |
2022-04-27
|
24 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Brian Haberman |
2022-04-27
|
24 | Éric Vyncke | Requested Last Call review by IOTDIR |
2022-04-27
|
24 | Éric Vyncke | Requested Last Call review by INTDIR |
2022-04-27
|
24 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-04-27
|
24 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-05-11): From: The IESG To: IETF-Announce CC: draft-ietf-drip-rid@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, tm-rid@ietf.org … The following Last Call announcement was sent out (ends 2022-05-11): From: The IESG To: IETF-Announce CC: draft-ietf-drip-rid@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, tm-rid@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)) to Proposed Standard The IESG has received a request from the Drone Remote ID Protocol WG (drip) to consider the following document: - 'DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2022-05-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). This document updates RFC7401 and RFC7343. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs self-attest to the included explicit hierarchy that provides registry (via, e.g., DNS, EPP) discovery for 3rd-party identifier attestation. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-drip-rid/ No IPR declarations have been submitted directly on this I-D. |
2022-04-27
|
24 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-04-27
|
24 | Éric Vyncke | Last call was requested |
2022-04-27
|
24 | Éric Vyncke | Last call announcement was generated |
2022-04-27
|
24 | Éric Vyncke | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-04-27
|
24 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-22 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-22 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document (1) specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track) and (2) updates RFC 7343 (also published in the Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a., UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation by the submission part of the datatracker and published as draft-ietf-drip-*; see https://datatracker.ietf.org/doc/draft-ietf-drip-uas-rid/history/). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification (HIP part), but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example), while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interoperability, this plan is OK as DETs are unambiguously identified by the prefix. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA against -13: add a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Éric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still displays the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publicly available stable specifications. (15) Are there downward normative references references (see RFC 3967)? Yes, RFC8032. RFC8032 is already listed in https://datatracker.ietf.org/doc/downref/. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry for DRIP. It also creates a two subregistries under that registry. The required policy for adding new entries is provided for each of these subregistries. o Updates a set of existing registries. The required information to complete the actions, including where to find the registries, is provided. (18) List any new IANA registries that require Expert Review for future allocations. "Hierarchical HIT (HHIT) Prefixes" (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-24
|
24 | Robert Moskowitz | New version available: draft-ietf-drip-rid-24.txt |
2022-04-24
|
24 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-24
|
24 | Robert Moskowitz | Uploaded new revision |
2022-04-21
|
23 | Robert Moskowitz | New version available: draft-ietf-drip-rid-23.txt |
2022-04-21
|
23 | Robert Moskowitz | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-21
|
23 | Robert Moskowitz | Uploaded new revision |
2022-04-13
|
22 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-22 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-22 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document (1) specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track) and (2) updates RFC 7343 (also published in the Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a., UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation and published as draft-ietf-drip-*). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification (HIP part), but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example), while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interoperability, this plan is OK as DETs are unambiguously identified by the prefix. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA against -13: add a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Éric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still displays the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publicly available stable specifications. (15) Are there downward normative references references (see RFC 3967)? Yes, RFC8032. RFC8032 is already listed in https://datatracker.ietf.org/doc/downref/. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry for DRIP. It also creates a two subregistries under that registry. The required policy for adding new entries is provided for each of these subregistries. o Updates a set of existing registries. The required information to complete the actions, including where to find the registries, is provided. (18) List any new IANA registries that require Expert Review for future allocations. "Hierarchical HIT (HHIT) Prefixes" (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-13
|
22 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-04-13
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-04-13
|
22 | Robert Moskowitz | New version available: draft-ietf-drip-rid-22.txt |
2022-04-13
|
22 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-13
|
22 | Robert Moskowitz | Uploaded new revision |
2022-04-11
|
21 | Éric Vyncke | Ballot writeup was changed |
2022-04-11
|
21 | Éric Vyncke | Ballot writeup was changed |
2022-04-11
|
21 | Éric Vyncke | Ballot writeup was changed |
2022-04-11
|
21 | Éric Vyncke | Send some comments after AD review, see https://mailarchive.ietf.org/arch/msg/tm-rid/ppyo2VILTgYG9J91TwsIh9XEEpY/ |
2022-04-11
|
21 | (System) | Changed action holders to Éric Vyncke, Andrei Gurtov, Robert Moskowitz, Stuart Card, Adam Wiethuechter (IESG state changed) |
2022-04-11
|
21 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-04-11
|
21 | Éric Vyncke | Ballot writeup was changed |
2022-04-10
|
21 | Éric Vyncke | RFC Editor Note for ballot was generated |
2022-04-10
|
21 | Éric Vyncke | RFC Editor Note for ballot was generated |
2022-04-10
|
21 | Éric Vyncke | RFC Editor Note for ballot was generated |
2022-04-10
|
21 | Éric Vyncke | Ballot approval text was generated |
2022-04-10
|
21 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-04-10
|
21 | Éric Vyncke | IESG state changed to AD Evaluation from Publication Requested |
2022-04-08
|
21 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document (1) specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track) and (2) updates RFC 7343 (also published in the Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a., UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation and published as draft-ietf-drip-*). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification (HIP part), but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example), while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interoperability, this plan is OK as DETs are unambiguously identified by the prefix. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA against -13: add a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Eric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still displays the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publicly available stable specifications. (15) Are there downward normative references references (see RFC 3967)? No. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry for DRIP. It also creates a two subregistries under that registry. The required policy for adding new entries is provided for each of these subregistries. o Updates a set of existing registries. The required information to complete the actions, including where to find the registries, is provided. (18) List any new IANA registries that require Expert Review for future allocations. "Hierarchical HIT (HHIT) Prefixes" (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-08
|
21 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document (1) specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track) and (2) updates RFC 7343 (also published in the Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a., UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation and published as draft-ietf-drip-uas-rid). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification, but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example) while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interperiablity, this plan is OK as DETs are unambiguously identified by the prefix. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA against -13: add a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Eric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still displays the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publically available stable specifications. (15) Are there downward normative references references (see RFC 3967)? No. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry for DRIP. It also creates a two subregistries under that registry. The required policy for adding new entries is provided for each of these subregistries. o Updates a set of existing registries. The required the information to complete the actions, including where to find the registries, is provided. (18) List any new IANA registries that require Expert Review for future allocations. "Hierarchical HIT (HHIT) Prefixes". (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-08
|
21 | Mohamed Boucadair | Responsible AD changed to Éric Vyncke |
2022-04-08
|
21 | Mohamed Boucadair | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-04-08
|
21 | Mohamed Boucadair | IESG state changed to Publication Requested from I-D Exists |
2022-04-08
|
21 | Mohamed Boucadair | IESG process started in state Publication Requested |
2022-04-08
|
21 | Mohamed Boucadair | Tag Doc Shepherd Follow-up Underway cleared. |
2022-04-08
|
21 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document (1) specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track) and (2) updates RFC 7343 (also published in the Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a., UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation and published as draft-ietf-drip-uas-rid). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification, but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example) while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interperiablity, this plan is OK as DETs are unambiguously identified by the prefix. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA against -13: add a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Eric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still displays the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publically available stable specifications. (15) Are there downward normative references references (see RFC 3967)? No. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry for DRIP. It also creates a two subregistries under that registry. The required policy for adding new entries is provided for each of these subregistries. o Updates a set of existing registries. The required the information to complete the actions, including where to find the registries, is provided. (18) List any new IANA registries that require Expert Review for future allocations. "Hierarchical HIT (HHIT) Prefixes". (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-08
|
21 | Robert Moskowitz | New version available: draft-ietf-drip-rid-21.txt |
2022-04-08
|
21 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-08
|
21 | Robert Moskowitz | Uploaded new revision |
2022-04-08
|
20 | Mohamed Boucadair | Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Shepherd write-up for draft-ietf-drip-rid-20 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests publication as a Proposed Standard RFC. That is indicated on the header page. The intended status is justified given that the document specifies a modified version of host identity tags (initially defined in RFC 7401 that was published in Standards Track). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies DRIP Entity Tags (DETs) that are used for drone identification purposes (a.k.a. UAS Remote ID). DETs rely upon Hierarchical Host Identity Tags (HHITs) which are defined as self-asserting IPv6 addresses. Also, these HHITs include explicit hierarchy to enable DNS queries and discovery of specific registrars for 3rd-party identification attestation purposes. Working Group Summary: This document ran 8 versions before adoption by the WG (including a version that passed surprisingly through without any validation and published as draft-ietf-drip-uas-rid). Regular slots were dedicated to this draft in several WG meetings. The authors implemented the outcomes of the discussions held in these meetings and the mailing list. Once the draft was adopted, a note was sent to HIPSEC mailing (https://mailarchive.ietf.org/arch/msg/ hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues with the specification, but no follow up message was received. Early SECDIR and IOTDIR reviews were requested by the Chairs against -07. These reviews were addressed by the authors. As suggested by the SECDIR reviewer, a review request was sent to the CFRG for review (31/08/2021). A discussion in the CFRG mailing list was then triggered: https://mailarchive.ietf.org/arch/msg/ cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes implemented in -11. A note was also sent to SAAG to seek for reviews, especially the privacy section (https://mailarchive.ietf.org/arch/msg/ saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-( The draft used to include some actions on behalf of the ICAO (RAA assignment, for example) while these are not formally discussed by the WG. These statements were removed and an action plan was agreed. The WG agreed that no RAA assignment policy will be included in this document. Such considerations (e.g., whether to abandon the control on the RAA assignment bound to the IANA-assigned prefix or keep the full control but have a provision for some delegation) will be covered in draft-ietf-drip-registries. From an interperiablity, this plan is OK as DETs are unambiguously identified by the prefix part. There was a concern whether /28 prefix is sufficient to cover any HHIT needs, not only DETs. The main outcomes were: o The IPv6 prefix is for DRIP use and, as such, the requested prefix size is reasonable. This block should be named "DRIP Device Entity Tags (DETs) Prefix" to avoid any confusion. o Maintain the request for the IANA /28 prefix. o Add a provision for the use of other prefixes, including network- specific prefixes. o To unambiguously identify a DET, create a new registry to list prefixes used for DET purposes. Some issues were reported by IANA raised issues against -13: a registration procedure for the new EdDSA Curve Label registry, indicate the upper boundary for the registry's Value field, etc. Some of these were fixed (see the IANA section). Sections 3.4.1 and 3.4.2 discusses HIP parameters that are impacted as a side effect of defining EdDSA as a HI algorithm. These parameters are not needed for DRIP. The draft includes two notes to make this clear enough. At least two implementations were reported to the WG, one of them is proprietary. Document Quality: The various reviews helped to enhance the quality of the document. Personnel: The document shepherd is Mohamed Boucadair The Responsible Area Director is Eric Vyncke (3) Briefly describe the review of this document that was performed by the Document Shepherd. At least three detailed reviews were made by the Document Shepherd: o -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ draft-ietf-drip-rid-07-rev%20Med.pdf o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts- Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/ draft-ietf-drip-rid-18-rev%20Med.pdf The authors have taken into account these various reviews. This version is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. (5) Do portions of the document need review from a particular or from broader perspective. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes. IPR responses can be seen at: * Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ * Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ * Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ * Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ (8) Has an IPR disclosure been filed that references this document? No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. Some issues were found and shared with the authors (e.g., citations in abstract, self-contained updated). These were fixed by the authors. Idnits still display the following: == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ... but all these are false positives: o The first nit is related to the affiliation of one of the co- authors. o The second nit is related to '100.hhit.arpa', but that's a valid example. o The third nit is related to the IANA IPv6 prefix. (12) Describe how the document meets any required formal review criteria No formal language is used. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs or publically available stable specifications. (15) Are there downward normative references references (see RFC 3967)? The document has the following: -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-CGA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-HIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPSECKEY' These references should be moved to be listed as Informative. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section. o The document creates a new registry (with two subregistries). The policy for adding new entries is not called out in the text to echo what is in the cited IANA-HIP registry. o Updates a set of existing registries. All the information to complete the actions, including where to find the registries, are provided. (18) List any new IANA registries that require Expert Review for future allocations. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A (20) If the document contains a YANG module N/A |
2022-04-07
|
20 | Robert Moskowitz | New version available: draft-ietf-drip-rid-20.txt |
2022-04-07
|
20 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-07
|
20 | Robert Moskowitz | Uploaded new revision |
2022-04-07
|
19 | Mohamed Boucadair | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2022-04-07
|
19 | Mohamed Boucadair | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-04-06
|
19 | Robert Moskowitz | New version available: draft-ietf-drip-rid-19.txt |
2022-04-06
|
19 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-04-06
|
19 | Robert Moskowitz | Uploaded new revision |
2022-04-01
|
18 | Mohamed Boucadair | Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) * A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) * -11 addresses the review from the cfrg * IANA raised issues against -13: From IANA: "The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.). The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?" * Shepherd Reviews: - 07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-rid-07-rev%20Med.pdf -18 https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-rid-18-rev%20Med.pdf - 13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf * IPR Checks -Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ - Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ - Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ - Andrei: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ * Implementations: - Andrei - Adam =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2022-03-31
|
18 | Robert Moskowitz | New version available: draft-ietf-drip-rid-18.txt |
2022-03-31
|
18 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2022-03-31
|
18 | Robert Moskowitz | Uploaded new revision |
2022-03-22
|
17 | Mohamed Boucadair | Removed from session: IETF-113: drip Wed-1300 |
2022-03-19
|
17 | Robert Moskowitz | New version available: draft-ietf-drip-rid-17.txt |
2022-03-19
|
17 | (System) | New version approved |
2022-03-19
|
17 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2022-03-19
|
17 | Robert Moskowitz | Uploaded new revision |
2022-03-19
|
16 | Robert Moskowitz | New version available: draft-ietf-drip-rid-16.txt |
2022-03-19
|
16 | (System) | New version approved |
2022-03-19
|
16 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2022-03-19
|
16 | Robert Moskowitz | Uploaded new revision |
2022-03-09
|
15 | Mohamed Boucadair | Added to session: IETF-113: drip Wed-1300 |
2021-12-08
|
15 | Robert Moskowitz | New version available: draft-ietf-drip-rid-15.txt |
2021-12-08
|
15 | (System) | New version approved |
2021-12-08
|
15 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-12-08
|
15 | Robert Moskowitz | Uploaded new revision |
2021-12-02
|
14 | Robert Moskowitz | New version available: draft-ietf-drip-rid-14.txt |
2021-12-02
|
14 | (System) | New version approved |
2021-12-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-12-02
|
14 | Robert Moskowitz | Uploaded new revision |
2021-12-02
|
13 | Mohamed Boucadair | Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) * A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) * -11 addresses the review from the cfrg * IANA raised issues against -13: From IANA: "The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.). The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?" * Shepherd Reviews: - 13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf - 07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-rid-07-rev%20Med.pdf * IPR Checks -Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/ - Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/ - Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/ - Andrei: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/ * Implementations: - Andrei - Adam =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-11-29
|
13 | Mohamed Boucadair | Some issues were raised in the list and also by IANA. Please discuss those and revise the document with the fixes. Thank you. |
2021-11-29
|
13 | Mohamed Boucadair | Tag Revised I-D Needed - Issue raised by WGLC set. |
2021-11-15
|
13 | Mohamed Boucadair | WGLC based on -13 This call will last until November 29, 2021. |
2021-11-15
|
13 | Mohamed Boucadair | IETF WG state changed to In WG Last Call from WG Document |
2021-11-11
|
13 | Mohamed Boucadair | Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) * A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) * -11 addresses the review from the cfrg * IANA raised issues against -13: From IANA: "The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.). The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?" =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-11-07
|
13 | Robert Moskowitz | New version available: draft-ietf-drip-rid-13.txt |
2021-11-07
|
13 | (System) | New version approved |
2021-11-07
|
13 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-11-07
|
13 | Robert Moskowitz | Uploaded new revision |
2021-11-02
|
12 | Stanislav Smyshlyaev | Added to session: IETF-112: cfrg Thu-1200 |
2021-10-26
|
12 | Mohamed Boucadair | Added to session: IETF-112: drip Thu-1430 |
2021-10-25
|
12 | Robert Moskowitz | New version available: draft-ietf-drip-rid-12.txt |
2021-10-25
|
12 | (System) | New version approved |
2021-10-25
|
12 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-10-25
|
12 | Robert Moskowitz | Uploaded new revision |
2021-10-22
|
11 | Mohamed Boucadair | Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) * A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) * -11 addresses the review from the cfrg =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-10-20
|
11 | Robert Moskowitz | New version available: draft-ietf-drip-rid-11.txt |
2021-10-20
|
11 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2021-10-20
|
11 | Robert Moskowitz | Uploaded new revision |
2021-09-20
|
10 | Mohamed Boucadair | Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) * A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-09-14
|
10 | Robert Moskowitz | New version available: draft-ietf-drip-rid-10.txt |
2021-09-14
|
10 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2021-09-14
|
10 | Robert Moskowitz | Uploaded new revision |
2021-08-31
|
09 | Mohamed Boucadair | Some notes: * a note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was … Some notes: * a note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received. * As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021) =============== As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-08-09
|
09 | Robert Moskowitz | New version available: draft-ietf-drip-rid-09.txt |
2021-08-09
|
09 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2021-08-09
|
09 | Robert Moskowitz | Uploaded new revision |
2021-07-29
|
08 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. Submission of review completed at an earlier date. |
2021-07-25
|
08 | Adam Wiethuechter | New version available: draft-ietf-drip-rid-08.txt |
2021-07-25
|
08 | (System) | New version approved |
2021-07-25
|
08 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-07-25
|
08 | Adam Wiethuechter | Uploaded new revision |
2021-07-23
|
08 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. |
2021-07-09
|
07 | Mohamed Boucadair | Added to session: IETF-111: drip Wed-1430 |
2021-07-08
|
07 | Michael Richardson | Request for Early review by IOTDIR Completed: Almost Ready. Reviewer: Michael Richardson. Sent review to list. |
2021-07-05
|
07 | Tero Kivinen | Request for Early review by SECDIR is assigned to Magnus Nystrom |
2021-07-05
|
07 | Tero Kivinen | Request for Early review by SECDIR is assigned to Magnus Nystrom |
2021-07-02
|
07 | Adam Montville | Assignment of request for Early review by SECDIR to Adam Montville was rejected |
2021-07-01
|
07 | Tero Kivinen | Request for Early review by SECDIR is assigned to Adam Montville |
2021-07-01
|
07 | Tero Kivinen | Request for Early review by SECDIR is assigned to Adam Montville |
2021-07-01
|
07 | Mohamed Boucadair | Notification list changed to mohamed.boucadair@orange.com because the document shepherd was set |
2021-07-01
|
07 | Mohamed Boucadair | Document shepherd changed to Mohamed Boucadair |
2021-06-29
|
07 | Mohamed Boucadair | This draft is related to remote identification of “drones”, that can be seen as “flying IoT” objects. We are looking for feedback related to the … This draft is related to remote identification of “drones”, that can be seen as “flying IoT” objects. We are looking for feedback related to the proposed solution given the constrained nature of such devices. Hence the iotdir review request. |
2021-06-28
|
07 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Michael Richardson |
2021-06-28
|
07 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Michael Richardson |
2021-06-28
|
07 | Mohamed Boucadair | Requested Early review by IOTDIR |
2021-06-28
|
07 | Mohamed Boucadair | Requested Early review by SECDIR |
2021-03-10
|
07 | Mohamed Boucadair | Changed consensus to Yes from Unknown |
2021-03-10
|
07 | Mohamed Boucadair | Intended Status changed to Proposed Standard from None |
2021-03-08
|
07 | Mohamed Boucadair | Added to session: IETF-110: drip Tue-1700 |
2021-01-28
|
07 | Robert Moskowitz | New version available: draft-ietf-drip-rid-07.txt |
2021-01-28
|
07 | (System) | New version approved |
2021-01-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2021-01-28
|
07 | Robert Moskowitz | Uploaded new revision |
2020-12-31
|
06 | Robert Moskowitz | New version available: draft-ietf-drip-rid-06.txt |
2020-12-31
|
06 | (System) | New version approved |
2020-12-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2020-12-31
|
06 | Robert Moskowitz | Uploaded new revision |
2020-12-22
|
05 | Robert Moskowitz | New version available: draft-ietf-drip-rid-05.txt |
2020-12-22
|
05 | (System) | New version approved |
2020-12-22
|
05 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card |
2020-12-22
|
05 | Robert Moskowitz | Uploaded new revision |
2020-11-01
|
04 | Robert Moskowitz | New version available: draft-ietf-drip-rid-04.txt |
2020-11-01
|
04 | (System) | New version accepted (logged-in submitter: Robert Moskowitz) |
2020-11-01
|
04 | Robert Moskowitz | Uploaded new revision |
2020-10-27
|
03 | Robert Moskowitz | New version available: draft-ietf-drip-rid-03.txt |
2020-10-27
|
03 | (System) | New version approved |
2020-10-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: Stuart Card , Adam Wiethuechter , Robert Moskowitz , Andrei Gurtov |
2020-10-27
|
03 | Robert Moskowitz | Uploaded new revision |
2020-10-27
|
02 | Mohamed Boucadair | Added to session: interim-2020-drip-07 |
2020-10-24
|
02 | (System) | This document now replaces draft-ietf-drip-uas-rid instead of None |
2020-10-24
|
02 | Robert Moskowitz | New version available: draft-ietf-drip-rid-02.txt |
2020-10-24
|
02 | (System) | New version approved |
2020-10-24
|
02 | (System) | Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Stuart Card , Robert Moskowitz , Andrei Gurtov |
2020-10-24
|
02 | Robert Moskowitz | Uploaded new revision |
2020-10-23
|
01 | Robert Moskowitz | New version available: draft-ietf-drip-rid-01.txt |
2020-10-23
|
01 | (System) | New version approved |
2020-10-23
|
01 | (System) | Request for posting confirmation emailed to previous authors: Stuart Card , Andrei Gurtov , Robert Moskowitz , Adam Wiethuechter |
2020-10-23
|
01 | Robert Moskowitz | Uploaded new revision |
2020-10-16
|
00 | Robert Moskowitz | New version available: draft-ietf-drip-rid-00.txt |
2020-10-16
|
00 | (System) | WG -00 approved |
2020-10-16
|
00 | Robert Moskowitz | Set submitter to "Robert Moskowitz ", replaces to (none) and sent approval email to group chairs: drip-chairs@ietf.org |
2020-10-16
|
00 | Robert Moskowitz | Uploaded new revision |