Subject: Issue #67 - Midi

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 28 Mar 2019 01:33:09 +0000

https://trac.ietf.org/trac/6man/ticket/67
Hi Midi, I believe the concerns you raised in issue #67 are resolved with the text proposed to Ron for Issue #38

  *   be explicit that padding objects are mandatory to implement/support.
     *   TLVs and HMAC are not mandatory
  *   whether HMAC is mandatory-to-implement/support?
     *   TLVs and HMAC are not mandatory
  *   what is the use of the HMAC flag?
     *   removed
  *   why the flag bits are separated from the tag field given that no concrete use is defined for the tag.
     *   Tag is defined.

Can you please verify this?

Darren

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 14:32:52 +0000

Hi Darren,

De : Darren Dukes (ddukes) [mailto:[email-masked]]
Envoyé : jeudi 28 mars 2019 02:33
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : Issue #67 - Midi

https://trac.ietf.org/trac/6man/ticket/67
Hi Midi,
[Med] I guess you meant Med!

I believe the concerns you raised in issue #67 are resolved with the text proposed to Ron for Issue #38
[Med] Let’s see.

[Med] In order to accommodate future TLVs, padding and HMAC are key to me. The base spec must be prepared to comply with padding requirement; that is why I tend to think that the support of these TLVs has the be indicated as mandatory to support/implement.

[Med] The draft says the following:

   SRH implementations can support multiple hash functions but MUST

                                                               ^^^^

   implement SHA-2 [FIPS180-4<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-17#ref-FIPS180-4>] in its SHA-256 variant.

     *   Removed

[Med] Great.

     *   Tag is defined.

[Med] The new text is not better compared to the previous one. That is still under-defined. I still don’t understand the usage/intent of that field and why it is not sufficient to provide the intended functionality by means of flow label or TC.

Darren