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

[[e-mail]]

Hi Bob, all,

Thanks for taking care of the comments.

Please inline some few items.

Cheers,
Med

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

I will go through IANA comments then push out -22 to the changes below:
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).



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

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


[snip]



# Sec 4.2

*** 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.

[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.

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?

[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.





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...
[Med] I suggest we expand C2 and point to 2.2 of 9153.




_________________________________________________________________________________________________________________________

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.