Subject: [Drip] Fw: New Version Notification for draft-wiethuechter-drip-auth-06.txt

From: Adam Wiethuechter <[email-masked]>
Date: Thu, 17 Dec 2020 20:00:58 +0000

All,

This newest revision is the last of the year for me on Authentication Formats.

I'd like to thank Soren Friis for giving me lots of great comments that this specific revision addresses.

  *   The document format has slightly changed. The payload formats are now defined under the data sections they reside in. I am not sure if this approach is clear, so feedback is welcome. My other idea was to create a subsection in each Frame format to describe payload types.
  *   Soren pointed out that Extended Adverts can only really send 9 frames/pages of data. His suggestion of using the 10th page only for Legacy and it be exclusively used for FEC is now added. Various data sizes were adjusted according to this new requirement.
  *   Soren pointed out that I was removing two bytes for the XOR operation. This has been changed to 1 and the ASTM Header is explicitly stated as existing but not in the diagrams.
  *   The FEC section now has subsections for encoding and decoding. This is to make the section a bit easier to parse. The text has also been updated and is a bit clearer on the process and reasonings.
  *   The Pseudo-Blockchain Hash section has been moved to the end of the Manifest section. Hopefully this will clear up some confusion as to what this section pertains to.
  *   Normalized the terminology in the Attestation Frame section. Numerous "assertions" were left behind in a copy paste.
  *   The former Bluetooth Format sections have been repurposed to be a section dedicated to recommendations based on the transport method.
  *   The ASTM Considerations section has some more explicit text as to what is being requested.
  *   All payload types/formats now have an explicit line to explain what the DRIP Header should be set to.
  *   The 5 Wrapped ASTM Messages section is still present but has an Editor's Note citing the issue Soren raised. Until we have a clear direction from ASTM on how they will proceed with Max Page Count I intend to keep the section.
  *   Attempted to better explain 0 Wrapped ASTM Messages -- might need a diagram? Comments would be appreciated.

Several TODOs have arose from the comments - mostly around going back to ASTM to get clarification.

  *   How does the AD Counter get used? (Should be specified in ASTM)
  *   Is there a way to define a "setID" for Authentication Messages? This would need to be on each page... Another discuss at ASTM.
  *   How do we handle the fact that Wifi NaN does not give the transmitters MAC Address to use for the hash operation in Manifest messages? I suggest we remove the MAC Address all together.

Questions, Comments and Concerns always welcome.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: [email-masked] <[email-masked]>
Sent: Thursday, December 17, 2020 2:29 PM
To: Adam Wiethuechter <[email-masked]>; Robert Moskowitz <[email-masked]>; Stuart Card <[email-masked]>
Subject: New Version Notification for draft-wiethuechter-drip-auth-06.txt

A new version of I-D, draft-wiethuechter-drip-auth-06.txt
has been successfully submitted by Adam Wiethuechter and posted to the
IETF repository.

Name:           draft-wiethuechter-drip-auth
Revision:       06
Title:          DRIP Authentication Formats
Document date:  2020-12-17
Group:          drip
Pages:          22
URL:            https://www.ietf.org/archive/id/draft-wiethuechter-drip-auth-06.txt
Status:         https://datatracker.ietf.org/doc/draft-wiethuechter-drip-auth/
Html:           https://www.ietf.org/archive/id/draft-wiethuechter-drip-auth-06.html
Htmlized:       https://tools.ietf.org/html/draft-wiethuechter-drip-auth-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wiethuechter-drip-auth-06

Abstract:
   This document describes how to include trust into the ASTM Remote ID
   specification defined in ASTM F3411-19 under a Broadcast Remote ID
   (RID) scenario.  It defines a few different message schemes (based on
   the Authentication Message) that can be used to assure past messages
   sent by a UA and also act as an assurance for UA trustworthiness in
   the absence of Internet connectivity at the receiving node.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat