Subject: [Drip] AD review of draft-ietf-drip-rid

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 11 Apr 2022 10:57:43 +0000

Hi,

Thanks to the authors, shepherd, and the DRIP WG for producing this 3rd I-D. And, I appreciate that the comments from iotdir, secdir, cfrg, .. were taken into accounts :-)

As usual, here is my AD review before going to the IETF Last Call and continuing the publication process. Except noted by a "***", all the comments can be ignored but I would appreciate a reply telling "we have read your comment but prefer to ignore" (or a variation of this text).

I hope this helps improving the document and ease the publication process.

Regards

-éric

---- review below

# Generic

Just curious, should the drip-arch document be mentioned somewhere ? E.g., in section 1

The text is really not consistent of using "HHIT" vs. "Hierarchical HIT" or "DET" vs "USA Remote ID DET" ... This does not help reading and understanding.

# Abstract

s/ (e.g., DNS, EPP)/ (via, e.g., DNS, EPP)/ ?

# Sect 1:

"Unmanned Aircraft System Remote Identification and tracking (UAS ID)" but RFC 9153 says " UAS ID UAS identifier.". Suggest being consistent and/or explain what the difference is.

Moreover, RFC 9153 has text about "DRIP identifier" and not about "UAD ID".

Please expand HIT and HIP at first use.

The discussion about PKI and X.509 certificate appears from nowhere, suggest having sub-section somewhere with justification of HHIT

# Sect 2.3:

s/ HDA (Hierarchical HIT Domain Authority)/ HDA (HHIT Domain Authority)/ ?

When defining HIP please add a reference to RFC.

# Sect 3

In figure 1, some early explanations about "orchid hash" would be welcome.

The text mention "context ID" but should it be "Orchid context ID" since IANA registry is about "CGA Type Tags" ? At least, a link to ORCHID should be given.

*** "A script for generating HHITs based on an early version of this specification is available at [hhit-gen].", it makes little sense to have an implementation of an outdated specification. Moreover, the link is 404 on github.

# Sec 3.1

Sometimes it is "HIP" and here it is "HIPv2", let's be consistent.

# Sec 3.2.1

Should the column heading be "HHIT Suite" rather than "HIT Suite" ?

"HDA Assigned" is rather unusual, why not using "experimental" or "private use" as it is often the case in other IANA registries ?

# Sec 3.3.1

As RAA has a length of 14 bit, I wonder what is the meaning of " RAA should be allocated in blocks with consideration on the likely size of a particular usage"

*** It is also unclear who allocates the RAA ? If IANA, then this should be in the IANA section. Else, please describe how colliding RAA are resolved/detected. I understand the registry I-D is coming but it is really puzzling for the reader. Did the author consider moving parts of the registry I-D in this section ? After all, it is more about the HHIT structure than registries interactions.

Which is " This DNS zone" ?

Should "100" rather be "decimal 100" ?

Should this be a "SHOULD" or even a "MUST" in "The PTR record could be constructed" ?

*** Even the registry I-D does not mention this PTR record and does not specify which party will own the "hhit.arpa" zone.

# Sec 3.3.2

It is useless to expand RVS as it has been done before.

s/RVS servers/RVSs/ ?

# Sec 3.4

Should "-Curve" be also in the section title ?

"HI" was already expanded before.

# Sec 3.5

The last sentence is about "addendum", are we sure that this I-D does not need to formally update ORCHID ?

# Sec 3.5.1

" This addendum will be constructed as follows": this is rather obscure.... What about something like "This document specifies another way to compute ORCHID".

Suggest using the same wording (e.g., for "Prefix") as in ORCHID.

Be clear that " p + n + o + m = 128 bits" is a MUST.

# Sec 3.5.2

Again "addendum" which is rather vague in an I-D.

" The cSHAKE function call for this addendum is" or should it be " The cSHAKE parameters for this addendum is"

# Sec 3.5.2.1 and 3.5.3 and 3.5.4

*** What is the intent of these sections ? It smells like it is really an argument to formally update ORCHID.

# Sec 4

Should the section title be " Hierarchical HITs as DRIP Entity Tags" ?

What is the purpose of the first paragraph ? It has already been said before.

" This hierarchy, cryptographically embedded within the HHIT, provides the information for finding the UA's HHIT registry", is it really "cryptographically embedded" ?

Is the ASTM part useful in this document ? I cannot see the link with DET.

# Sec 4.2

*** Please provide a normative reference to base32.

The discussion about not using base34 may be skipped IMHO.

*** " A mapping service (e.g., DNS) MUST provide a trusted" is really hand waving and I am unsure how DNS could be use there. How useful is this spec if there is no mapping ? Should this be a IANA registry ?

# Sec 4.5

The 2nd paragraph is nice but should perhaps be moved in the RAA section ?

# Sec 4.6

*** What is " ASTM Authentication Message" (at least provide some references).

# Sec 5

" The following are examples of how this may be done".... and this I-D is assumed to be standard track. I.e., it should either use normative language or be removed IMHO (as it is probably better in the registries I-D).

Should 100 and 50 be prefixed by "decimal" ?

s/ following: Assume/ following: assume/

" A secure connection (e.g., DNS-over-TLS [RFC7858]) to the authoritative zone may be a viable alternative to DNSSEC." But I wonder whether the authoritative servers (and not zone BTW) will be happy with the load...

The "ipv6.arpa" example is missing the value for the PTR RR.

# Sec 6 and 7

Unsure whether these 2 small sections belong to this document. Suggest to remove them.

# Sec 8

At the authors' discretion, this section could become part of the security considerations (and it could also be renamed in 'Privacy Considerations')

" through address randomization", which address ? MAC ?

Please explain what "PHY" and "C2" are ;-)

In " Simply changing the UAS RID" should this rather be DET ?

# Sect 9.5:

Should it be before section 9.1 as if request the allocation of /28 to be used in section 9.1 ?

" DRIP Device Entity Tags" ? or " DRIP Entity Tags" ?

# Sec 10

*** Please provide a reference to "a Python script"

About the " *single* bitcoin mining ASIC", it is about the sha256 performance but I would assume that creating a key pair is more computing intensive than a sha256, if confirmed (I am not a crypto guy), then how relevant is this number ?

What is " receiver of the DET" ? (I understand of course but rather use correct wording)

" As such, use of DNSSEC and DNS-over-TLS by the DET registries is recommended" some justifications would be welcome as DNSSEC & DoT are vastly different beasts with different objectives.

" Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object" is it part of this specification? Else, please add something "out of scope"

This section would benefit from having a little more structure with more sub-sections (e.g., collision)

What about having a few paragraphs about revocation ?

# Sec 10.1

*** Should the title include ASTM ? Because, it seems that it is only about ASTM

# Sec 11.2

*** F3411 & drip-registries & CTA2063A & RFC 8032 should probably be normative.

App A

While interesting read, what is the link with DET ? Will DET comply with the EU rule?

App B

Humm DET could also be used by other industries, e.g., rail transportation or sea shipping.

---

From: <[email-masked]>
Date: Mon, 11 Apr 2022 11:38:36 +0000

Hi Éric,

Thank you for the careful AD review.

Please see below for one specific point.

Cheers,
Med

De : Tm-rid <[email-masked]> De la part de Eric Vyncke (evyncke)
Envoyé : lundi 11 avril 2022 12:58
À : [email-masked]
Cc : [email-masked]
Objet : [Drip] AD review of draft-ietf-drip-rid

Hi,

Regards

-éric

---- review below

[snip] …

# Sec 11.2

[Med] You are probably right for RFC8032. The good news is that it is already listed in https://datatracker.ietf.org/doc/downref/.

F3411 is cited once to call out the various types. Reading that document is not required to understand or implement HHITs/DETs.

Idem for drip-registries. What is important from an interoperability standpoint is to unambiguously identify a DET. This is done by means of the prefix part. How the RAA/HDA parts are assigned does not actually matter.

I’m neutral on CTA2063A.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 11 Apr 2022 08:54:13 -0400

Eric,

Thank you for your comments.  I am starting on the next ver...

On 4/11/22 06:57, Eric Vyncke (evyncke) wrote:
>
> Hi,
>
> Thanks to the authors, shepherd, and the DRIP WG for producing this 
> 3rd I-D. And, I appreciate that the comments from iotdir, secdir, 
> cfrg, .. were taken into accounts :-)
>
> As usual, here is my AD review before going to the IETF Last Call and 
> continuing the publication process. Except noted by a "***", all the 
> comments can be ignored but I would appreciate a reply telling "we 
> have read your comment but prefer to ignore" (or a variation of this 
> text).
>
> The text is really not consistent of using "HHIT" vs. "Hierarchical 
> HIT" or "DET" vs "USA Remote ID DET" ... This does not help reading 
> and understanding.
>
> # Abstract
>
> "Unmanned Aircraft System Remote Identification and tracking (UAS ID)" 
> but RFC 9153 says " UAS ID UAS identifier.". Suggest being consistent 
> and/or explain what the difference is.
>
> The discussion about PKI and X.509 certificate appears from nowhere, 
> suggest having sub-section somewhere with justification of HHIT
>
> # Sect 2.3:
>
> The text mention "context ID" but should it be "Orchid context ID" 
> since IANA registry is about "CGA Type Tags" ? At least, a link to 
> ORCHID should be given.
>
> *** "A script for generating HHITs based on an early version of this 
> specification is available at [hhit-gen].", it makes little sense to 
> have an implementation of an outdated specification. Moreover, the 
> link is 404 on github.
>
> # Sec 3.1
>
> "HDA Assigned" is rather unusual, why not using "experimental" or 
> "private use" as it is often the case in other IANA registries ?
>
> # Sec 3.3.1
>
> As RAA has a length of 14 bit, I wonder what is the meaning of " RAA 
> should be allocated in blocks with consideration on the likely size of 
> a particular usage"
>
> *** It is also unclear who allocates the RAA ? If IANA, then this 
> should be in the IANA section. Else, please describe how colliding RAA 
> are resolved/detected. I understand the registry I-D is coming but it 
> is really puzzling for the reader. Did the author consider moving 
> parts of the registry I-D in this section ? After all, it is more 
> about the HHIT structure than registries interactions.
>
> *** Even the registry I-D does not mention this PTR record and does 
> not specify which party will own the "hhit.arpa" zone.
>
> # Sec 3.3.2
>
> " This addendum will be constructed as follows": this is rather 
> obscure.... What about something like "This document specifies another 
> way to compute ORCHID".
>
> " This hierarchy, cryptographically embedded within the HHIT, provides 
> the information for finding the UA's HHIT registry", is it really 
> "cryptographically embedded" ?
>
> *** " A mapping service (e.g., DNS) MUST provide a trusted" is really 
> hand waving and I am unsure how DNS could be use there. How useful is 
> this spec if there is no mapping ? Should this be a IANA registry ?
>
> # Sec 4.5
>
> " The following are examples of how this may be done".... and this I-D 
> is assumed to be standard track. I.e., it should either use normative 
> language or be removed IMHO (as it is probably better in the 
> registries I-D).
>
> " A secure connection (e.g., DNS-over-TLS [RFC7858]) to the 
> authoritative zone may be a viable alternative to DNSSEC." But I 
> wonder whether the authoritative servers (and not zone BTW) will be 
> happy with the load...
>
> At the authors' discretion, this section could become part of the 
> security considerations (and it could also be renamed in 'Privacy 
> Considerations')
>
> About the " *single* bitcoin mining ASIC", it is about the sha256 
> performance but I would assume that creating a key pair is more 
> computing intensive than a sha256, if confirmed (I am not a crypto 
> guy), then how relevant is this number ?
>
> " As such, use of DNSSEC and DNS-over-TLS by the DET registries is 
> recommended" some justifications would be welcome as DNSSEC & DoT are 
> vastly different beasts with different objectives.
>
> " Another mitigation of HHIT hijacking is if the HI owner (UA) 
> supplies an object" is it part of this specification? Else, please add 
> something "out of scope"
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 11 Apr 2022 08:59:42 -0400

Responses inline.

On 4/11/22 07:38, [email-masked] wrote:
> *De :* Tm-rid <[email-masked]> *De la part de* Eric Vyncke 
> (evyncke)
> *Envoyé :* lundi 11 avril 2022 12:58
> *À :* [email-masked]
> *Cc :* [email-masked]
> *Objet :* [Drip] AD review of draft-ietf-drip-rid
>
> Hi,
>
> */[snip] /*…
> */[Med] You are probably right for RFC8032. The good news is that it 
> is already listed in https://datatracker.ietf.org/doc/downref/. /*
>

Normative.

> *//*
>
> *//*
>
> */F3411 is cited once to call out the various types. Reading that 
> document is not required to understand or implement HHITs/DETs. /*
>
> *//*
>
> */Idem for drip-registries. What is important from an interoperability 
> standpoint is to unambiguously identify a DET. This is done by means 
> of the prefix part. How the RAA/HDA parts are assigned does not 
> actually matter. /*
>
> *//*
>
> */I’m neutral on CTA2063A./*
>

All informative, IMHO.  Sec 4.2 is how to do DET within CTA2063A if this 
is your representational mode.  Everything about 2063A is included in 
this section, except how to register with ICAO to get a Manf code (with 
is not specified by CTA).  Thus the reader does not need the CTA document.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 13 Apr 2022 11:21:40 -0400

I will go through IANA comments then push out -22 to the changes below:

> Just curious, should the drip-arch document be mentioned somewhere ? 

hmm.. a chicken and egg problem.  I am looking into it.

> HIT" or "DET" vs "USA Remote ID DET" ... This does not help reading 

I cannot find "USA Remote ID DET" anywhere in the draft.

Should all occurrences of "Hierarchical HIT" after the first be replaced 
with HHIT?

Per the Intro:

    HHITs as used within the context of Unmanned Aircraft System (UAS)
    are labeled as DRIP Entity Tags (DETs).  Throughout this document
    HHIT and DET will be used appropriately.  HHIT will be used when
    covering the technology, and DET for their context within UAS RID.

I think I have been consistent in following this.  But I am open to 
careful review and changes for closer adherence.

> s/ (e.g., DNS, EPP)/ (via, e.g., DNS, EPP)/ ?

Done

> and/or explain what the difference is.

hmm.  F3411-19 says: "Standard Specification for Remote ID and Tracking"

I wrote my text before req was far along, and have not looked back...

I will align with 9153.

And F3411-22 seems to have:

1 – Internet Engineering Task Force (IETF) Drone Remote Identification 
Protocol (DRIP) entity ID.

I will have to see if we can still r/Identification/ID/  or if we are 
too far into the publication process...

Don't know if I can fix this in all the places anymore...

> Moreover, RFC 9153 has text about "DRIP identifier" and not about "UAD 

Sigh.  We tend to get wrapped around the wagon wheel on Identity and 
Identifier.  Supposedly Identifier when talking about the what and 
Identity for the how.  I think.

> Please expand HIT and HIP at first use.

Think I got this.

> suggest having sub-section somewhere with justification of HHIT

See sec 1.1.

> s/ HDA (Hierarchical HIT Domain Authority)/ HDA (HHIT Domain Authority)/ ?

done

> When defining HIP please add a reference to RFC.

Think I got it.

> In figure 1, some early explanations about "orchid hash" would be welcome.

Should I end the 1st sentence in Sec 3 with "] hash." ?

As here is where I say what ORCHID is.

> since IANA registry is about "CGA Type Tags" ? At least, a link to 

the beginning of sec 3 references 7343.  7343 just says "context ID" and 
I was following that pattern.  Every usage of "context ID" pertains to 
ORCHIDs.  I could see this if there was some other "context ID" in this 
document?

> have an implementation of an outdated specification. Moreover, the 

r/master/main/  it seems.

Can't maintain it myself.  Can't talk anyone into doing it.  Sigh, away 
it goes.  Did serve a purpose early on.

> Sometimes it is "HIP" and here it is "HIPv2", let's be consistent.

I feel that the places I use HIPv2 are appropriate as it refers 
specifically to HIPv2 items.  Now should all the HIP move to HIPv2? I 
think there is similarity to IKE and IKEv2.  But I will follow editorial 
guidance.

> Should the column heading be "HHIT Suite" rather than "HIT Suite" ?

oops.  done.

> "private use" as it is often the case in other IANA registries ?

I went with "HDA Private Use" as I want to reflect this is HDA-bound.

> should be allocated in blocks with consideration on the likely size of 

I think that should be "RAAs should".  That an entity running an RAA, 
like the US Gov, would want to separate commercial from rec from mil.

> about the HHIT structure than registries interactions.

This is a disagreement between authors and chairs.  I don't see the IANA 
having the expertise to handle this.  It will take some organization 
like ICAO or IATA or other aviation alphabet soup to determine the 
allocation.  Why add the IANA into the mix?  I was instructed to pull 
ICAO; I do not have official ICAO 'approval' that they will do this.  I 
will point out that they manage a LOT of number spaces for aviation; 
2063 Manufacture Code is only one.  And they do that for CTA/ASTM.

So that is why I have the basics here with pointers to registries to 
kick the can down the road.

> Which is " This DNS zone" ?

changed.

> Should "100" rather be "decimal 100" ?

Grumble.  changed here and sec 5.
> Should this be a "SHOULD" or even a "MUST" in "The PTR record could be 

It is an example.

> not specify which party will own the "hhit.arpa" zone.

Note added that IF this zone is used and it is for all HHITs, then IANA 
delegated.  This though makes the whole thing complex.

> It is useless to expand RVS as it has been done before.

Done

> Should "-Curve" be also in the section title ?

Yes.

> "HI" was already expanded before.

I do loose track in edits/adds on things like this.  thanks for catching it.

> not need to formally update ORCHID ?

I now say 'update' in the intro, so thanks for catching this.  It is now 
also update.

> Suggest using the same wording (e.g., for "Prefix") as in ORCHID.

Prefix (p)      : An IPv6 prefix of length p (max 28-bit-long).

> Be clear that " p + n + o + m = 128 bits" is a MUST.

added.

> cSHAKE parameters for this addendum is"

More of them?  Must have been copy and paste in the original writing.  
All changed.

> an argument to formally update ORCHID.

I now say "update".  Do I need more?

> Should the section title be " Hierarchical HITs as DRIP Entity Tags" ?

Much simpler.

> What is the purpose of the first paragraph ? It has already been said 

Organic nature of draft development.  It is gone now.

> "cryptographically embedded" ?

r/embedded/bound/

> Is the ASTM part useful in this document ? I cannot see the link with DET.

this is where DET is referenced outside of IETF.  Thus important.  I 
have simplified the text.

> *** Please provide a normative reference to base32.

What?  I learned this terminology back in 11th grade in 1966!  We used 
it in FORTRAN programming in CPS301 in 1968 at Michigan State U on our 
CDC6500 (for extra credit, my program converted any base to any base).  
There is a reference for this?  I never knew...

It was just part of the whole "what base does your computer use." 
thing.  We had fun with DECs with their 7-bit words.  CDC was 8-bit 
(Octal) but the math registers were 60-bit.  Did fun things with those.

> The discussion about not using base34 may be skipped IMHO.

I am willing to gut it (I was going to say 'cut' but I think the typo is 
more fun!).  Other opinions?

> this spec if there is no mapping ? Should this be a IANA registry ?

Grumble.  What was I thinking...

ICAO manages the CTA 2063 manufacture code registry.  Right now easy to 
get one via email.  Stu got one for his company's UA.  I imagine this as 
being an adjunct to the current ICAO process.  The company will provide 
the prefix|HID they want associated with their code. ICAO will add this 
to their registry.  This would be an addition to the current ICAO GRAIN 
DNS work I am part of.

This process may end up as part of drip-registries or just an ICAO 
process addition to the current CTA manf code registry.

> The 2nd paragraph is nice but should perhaps be moved in the RAA section ?

Moved, but altered to fit in 3.3

4.5 may now need further work.

> *** What is " ASTM Authentication Message" (at least provide some 

I had, but Med had me pull:

    In practice, the Wrapper and Manifest authentication formats in the
    ASTM Authentication Message (Msg Type 0x2) [drip-authentication]
    implicitly provide this self-attestation.  A lookup service like DNS
    can provide the HI and registration proof (GEN-3 in [RFC9153]).

changed to

    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

Please offer a compromise?

> Should 100 and 50 be prefixed by "decimal" ?

Did.

> s/ following: Assume/ following: assume/

done

> wonder whether the authoritative servers (and not zone BTW) will be 

It is a problem.  But others have stated this is nothing compared to 
other loads.

> The "ipv6.arpa" example is missing the value for the PTR RR.

This crept in ver -04.  I had to go back and see what I cut.  I can kind 
of remember why, as if you look at -03 I did not use this format.  So I 
will slap something in.  It is all examples...

> Unsure whether these 2 small sections belong to this document. Suggest 

For 6, I will change might to will, as I know of work-in-progress.

For 7, Adam and I have debated how to point out what reqs met. 
Originally I did not have this section, but as he had this in auth, I 
mirrored it.  So we both need AD advise.  For myself, I don't see the 
need of this summary.  I have embedded, at each point, where reqs are met.

> security considerations (and it could also be renamed in 'Privacy 

Done

> " through address randomization", which address ? MAC ?

Added MAC.

> Please explain what "PHY" and "C2" are ;-)

C2 defined in 9153 as Command and Control.

PHY is Physical Layer.  Standard usage when mentioning PHY/MAC tech like 
BT and WiFi.  I have never seen it expanded in IETF stuff, but can...

> In " Simply changing the UAS RID" should this rather be DET ?

Well actually it applies to ALL of the RID types, but those are out of 
scope so changed to DET.

> Should it be before section 9.1 as if request the allocation of /28 to 

probably.  Let me see what IANA said and include this in their changes.

> " DRIP Device Entity Tags" ? or " DRIP Entity Tags" ?

DRIP Entity Tags (DETs)

Is what is used elsewhere.

> *** Please provide a reference to "a Python script"

 From the authors?  We are not posting this script.

A script is was used to randomly generate 1M HHITs

???

> guy), then how relevant is this number ?

Numbers on keypair generation is a few times more than sha256 computes, 
so these people look at it as, "so it takes 3x more time total, big 
deal."  They look at it as we can do lots of sha256, we can do lots of 
keypair gens.

> What is " receiver of the DET" ? (I understand of course but rather 

    This attack can be mitigated by the
    receiver of messages containing DETs using DNS to find the HI for the
    DET.

> vastly different beasts with different objectives.

     As such, use of DNSSEC by the DET registries is
     recommended to provide trust in HI retrieval.

> supplies an object" is it part of this specification? Else, please add 

ref drip-auth.

> more sub-sections (e.g., collision)

I will think about a sub-section at:

"The two risks with hierarchical", but it is not forthcoming...

> What about having a few paragraphs about revocation ?

I will have to look back at what we told Valery on this.  Not for -22.  
I am running out of time before Passover.

> *** Should the title include ASTM ? Because, it seems that it is only 

title changed.

> *** F3411 & drip-registries & CTA2063A & RFC 8032 should probably be 

8032 yes, others no.  I think.

> While interesting read, what is the link with DET ? Will DET comply 

Open to moving this elsewhere, but want guidance.

> transportation or sea shipping.

YEP!

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 06:35:01 +0000

Hi Bob, all,

Thanks for taking care of the comments.

Please inline some few items.

Cheers,
Med

De : Tm-rid <[email-masked]> De la part de Robert Moskowitz
Envoyé : mercredi 13 avril 2022 17:22
À : Eric Vyncke (evyncke) <evyncke=[email-masked]>; [email-masked]
Cc : [email-masked]
Objet : Re: [Drip] AD review of draft-ietf-drip-rid

Hi,

Regards

-éric

---- review below

# Generic

[snip]

# Sec 4.2

What?  I learned this terminology back in 11th grade in 1966!  We used it in FORTRAN programming in CPS301 in 1968 at Michigan State U on our CDC6500 (for extra credit, my program converted any base to any base).  There is a reference for this?  I never knew...

It was just part of the whole "what base does your computer use." thing.  We had fun with DECs with their 7-bit words.  CDC was 8-bit (Octal) but the math registers were 60-bit.  Did fun things with those.

[Med] Éric’s comment is fair. I suggest we point to RFC4648. Thanks.

[snip]

# Sec 4.6

*** What is " ASTM Authentication Message" (at least provide some references).
[Med] This is defined in RFC9153:

   Authentication Message

      [F3411-19<https://datatracker.ietf.org/doc/html/rfc9153#ref-F3411-19>] Message Type 2.  Provides framing for authentication

      data only; the only message that can be extended in length by

      segmenting it across more than one page.

changed to

[Med] I suggest we maintain the text you quoted, but make this change:

OLD:

   However,
   such an object would just fit in the ASTM Authentication Message with
   no room for growth.

NEW:

However,

   such an object would just fit in the ASTM Authentication Message

   (Section 2.2 of [RFC9153] with no room for growth.

PHY is Physical Layer.  Standard usage when mentioning PHY/MAC tech like BT and WiFi.  I have never seen it expanded in IETF stuff, but can...
[Med] I suggest we expand C2 and point to 2.2 of 9153.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 14 Apr 2022 06:43:42 +0000

Thank Med for your review of the review ;-)

Your suggestions are good for me, I would still use "Authentication Message" rather than "ASTM Authentication Message" (RFC 9153 uses the former)

Regards

-éric

From: "[email-masked]" <[email-masked]>
Date: Thursday, 14 April 2022 at 08:35
To: Robert Moskowitz <[email-masked]>, Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Drip] AD review of draft-ietf-drip-rid

Hi Bob, all,

Cheers,
Med

Hi,

Regards

-éric

---- review below

# Generic

[snip]

# Sec 4.2

# Sec 4.6

   Authentication Message

changed to

OLD:

   However,

NEW:

However,

Thank you.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 14 Apr 2022 08:33:25 -0400

see me response.

On 4/14/22 02:35, [email-masked] wrote:
> *De :*Tm-rid <[email-masked]> *De la part de* Robert Moskowitz
> *Envoyé :* mercredi 13 avril 2022 17:22
> *À :* Eric Vyncke (evyncke) <evyncke=[email-masked]>; 
> [email-masked]
> *Objet :* Re: [Drip] AD review of draft-ietf-drip-rid
>
>     Thanks to the authors, shepherd, and the DRIP WG for producing
>     this 3rd I-D. And, I appreciate that the comments from iotdir,
>     secdir, cfrg, .. were taken into accounts :-)
>
>     As usual, here is my AD review before going to the IETF Last Call
>     and continuing the publication process. Except noted by a "***",
>     all the comments can be ignored but I would appreciate a reply
>     telling "we have read your comment but prefer to ignore" (or a
>     variation of this text).
>
> CDC6500 (for extra credit, my program converted any base to any 
> base).  There is a reference for this?  I never knew...
>
> */[Med] Éric’s comment is fair. I suggest we point to RFC4648. Thanks. /*
>

Interesting.  over 40 year old terminology defined.  :)

But the base32 encoding there is not what I specified.  Simplest is use 
of '1' and 'I'.  CTA 2063A says:

    MFR SN       : Alphanumeric code (0-9, A-Z except O and I).
                    Maximum length of 15 characters.

But 4648 says:

                      Table 3: The Base 32 Alphabet

      Value Encoding  Value Encoding  Value Encoding  Value Encoding
          0 A             9 J            18 S            27 3
          1 B            10 K            19 T            28 4
          2 C            11 L            20 U            29 5
          3 D            12 M            21 V            30 6
          4 E            13 N            22 W            31 7
          5 F            14 O            23 X
          6 G            15 P            24 Y         (pad) =
          7 H            16 Q            25 Z
          8 I            17 R            26 2

Thus they are not compatible.

>
> [snip]
>
>     # Sec 4.6
>
>     *** What is " ASTM Authentication Message" (at least provide some
>     references).*//*
>
> */[Med] This is defined in RFC9153:/*
>
> *//*
>
>    Authentication Message
>       [F3411-19  <https://datatracker.ietf.org/doc/html/rfc9153#ref-F3411-19>] Message Type 2.  Provides framing for authentication
> */[Med] I suggest we maintain the text you quoted, but make this change:/*
>
>
> */OLD:/*
>
>    However,
>
> PHY is Physical Layer.  Standard usage when mentioning PHY/MAC tech 
> like BT and WiFi.  I have never seen it expanded in IETF stuff, but can...
>
> */[Med] I suggest we expand C2 and point to 2.2 of 9153. /*
>

2.3 of drip-rid says to look at 2.2 of 9153.  I should repeat that here?

Also C2 is first used in sec 6.  I would think this is where I expand 
it, not 9.2

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 13:10:03 +0000

Hi Rob,

Please see inline.

Cheers,
Med

De : Robert Moskowitz <[email-masked]>
Envoyé : jeudi 14 avril 2022 14:33
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Eric Vyncke (evyncke) <evyncke=[email-masked]>; [email-masked]
Cc : [email-masked]
Objet : Re: [Drip] AD review of draft-ietf-drip-rid

see me response.
On 4/14/22 02:35, [email-masked]<mailto:[email-masked]> wrote:

[snip]

# Sec 4.6

   Authentication Message

changed to

OLD:

   However,

NEW:

However,

2.3 of drip-rid says to look at 2.2 of 9153.  I should repeat that here?
[Med] Yes, please.
Also C2 is first used in sec 6.  I would think this is where I expand it, not 9.2

[Med] Indeed.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 14 Apr 2022 09:27:53 -0400

Started -23 with this change to sec 6.

On 4/14/22 09:10, [email-masked] wrote:
>
> Hi Rob,
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :* Robert Moskowitz <[email-masked]>
> *Envoyé :* jeudi 14 avril 2022 14:33
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Eric 
> Vyncke (evyncke) <evyncke=[email-masked]>; [email-masked]
>         *** What is " ASTM Authentication Message" (at least provide
>         some references).*//*
>
>     PHY is Physical Layer.  Standard usage when mentioning PHY/MAC
>     tech like BT and WiFi.  I have never seen it expanded in IETF
>     stuff, but can...
>
> */[Med] Yes, please./*
> */[Med] Indeed.
> /*