Re: [ippm] A review of draft-zhou-ippm-enhanced-alternate-marking-08

[Adrian Farrel <[e-mail]>]

Thanks Giuseppe,

All looks good.

Adrian

-----Original Message-----
From: Giuseppe Fioccola <[e-mail]> 
Sent: 14 February 2022 15:01
To: [e-mail]; [e-mail]
Cc: 'IETF IPPM WG' <[e-mail]>
Subject: RE: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Hi Adrian,
Thanks a lot for your thorough revision. 
It will help to improve the document and we plan to publish the new revision
soon.

Please find my responses inline as [GF].

Best Regards,

Giuseppe

-----Original Message-----
From: Adrian Farrel <[e-mail]> 
Sent: Friday, February 11, 2022 2:54 PM
To: [e-mail]
Cc: 'IETF IPPM WG' <[e-mail]>
Subject: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Hi,

I've just been looking at draft-ietf-6man-ipv6-alt-mark, so I thought I
would also have a look at this draft.

Here are a few comments that the authors may find helpful.

Best,
Adrian

===

Abstract

1. Don't use references in the Abstract
2. It would be really nice to say which enhanced capabilities and
   functions are provided and allowed.
3. s/the enhanced/enhanced/

[GF]: Sure, I will apply these changes and specify what are the enhanced
capabilities, for example thicker packet loss measurements and more dense
delay measurements with no limitation for the number of concurrent flows
under monitoring

---

Requirements language

1. You should move this down into section 1.1 2. You need to use the
up-to-date boilerplate

[GF]: Yes, we will do.

---

Section 1

1. s/an hybrid/a hybrid/
2. s/IPv6 AltMark Option/The IPv6 AltMark Option/ 3. s/to the IPv6
protocol/to IPv6/ 4. s/defines Extension/defines an Extension/ 5. s/encode
Alternate/encode the Alternate/ 6. s/both Hop-by-Hop/both the Hop-by-Hop/ 7.
s/and Destination/and the Destination/ 8. s/carried as SRH TLV/carried as a
TLV in the Segment Routing Header/

[GF]: We will include these changes.

9. You have...
   While the AltMark Option implements the basic alternate marking
   method, this document defines the extended data fields for the
   AltMark Option and provides the enhanced capabilities.
   ...I'm not clear, but I think, s/the extended/extended/ and
   s/the enhanced/enhanced/
   But I think that the Introduction (in more detail than the Abstract) 
   needs to give clues about those capabilities.

[GF]: We will apply the suggested changes. I agree that more detailed
information about the enhanced capabilities can be included in the
Introduction.
---

Section 2

1. s/the next figure/Figure 1/
2. s/An 8 bits/An 8-bit/

[GF]: We will include these changes.

3. It is not clear from the text that two bits of the former Reserved
   field remain reserved, are shown as R in the figure, and MUST continue
   to be set to zero on transmission and ignored on receipt.

[GF]: We will clarify this point.

4. s/Fig. 1:/Figure 1:/   (same for all the figures)

[GF]: Yes.

5. Figure 1 is slightly confusing as Section 3.1 of draft-ietf-6man-ipv6
   -alt-mark shows two additional fields (Option Type and Opt Data Len) 8.
Do you really need 8 bits for the NextHeader field. You have reserved 
   0-8 for special purposes, and used just one other value (9). At the 
   same time you have removed 8 out of the 10 bits available for future
   extensions. Furthermore, 8 values looks like a lot of experimentation
   space. Why not...
   - Keep zero as reserved (for backward compatibility - by the way, you 
     should say in the text why zero is reserved)
   - Reduce experimentation to the values 1, 2, 3
   - Assign just 4 bits for "NextHeader"

[GF]: This is a good suggestion. It looks reasonable to reduce the number of
bits for NextHeader.

7. I really feel that you are going to need a registry for the values of
   the NextHeader field.
8. s/The following figure/Figure 2/

[GF]: We will include these changes.

9. You have ...
   o  Flag - A 4 bits flag to indicate the special purpose usage.
   ...It's OK, but could you add "(see below)" to save me from panic.

[GF]: Sure, good suggestion.

10. s/A 4 bits flag/A 4-bit flag/
11. For Len ("It indicates the length of extension headers.") you need
   to say what is counted and in what units. Do you start at FlowMonID
   Ext or after Padding? Do you count in octets or double words?
12. s/A 16 bits Bitmap/A 16-bit bitmap/

[GF]: We will do.

13. To be clear, is the padding there specifically as padding, or is a 
    reserved field? What does "when not being used" mean? Looking later
    I think that you only have padding present sometimes, so it is 
    genuinely padding, but the text does not explain when it is there and
    when it isn't.

[GF]: We can clarify that padding is a variable length field as further
specify later in the document.

14. s/requested to set/requested to be set/ 15. Similarly for MetaInfo,
could you add "(see below)"?
16. s/The Flag is defined as/The Flag is defined in Figure 3 as/ 
17. OLD
    others - Reserved.
    NEW
    others (shown as R) - Reserved. MUST be set to zero and ignored on
    receipt.
    END
18. s/as a bit map as follows:/in Figure 4 as a bit map as follows:/ 

[GF]: We will apply these changes.

19. I read "stands for the second part" several times before I realised
    you mean "stands of the number of seconds in the timestamp" and not
    "the second part of the timestamp"!

[GF]: We will revise the text.

20. I see that various pieces of information are present if a particular
    bit in the bitmap is set. But you don't talk about whether that 
    information must be ordered according to the order of the bits (of
    course it must be).

[GF]: Yes, we will clarify this point.

21. Figure 6 shows Control as a 6-bit field and Period as a 10-bit 
    field. If this is an error, fix the figure. If it is intentional
    please make it clear in the text.

[GF]: We will further clarify this part.

22. How are the various fields of the control information extension 
    used? I feel you may be missing some reference pointers.
23. What is the sequence number used for?

[GF]: We will add further details here.

---

Section 3.

   In particular the fundamental
   security requirement is that Alternate Marking MUST be applied in a
   specific limited domain, as also mentioned in [RFC8799].

It's subtle, but I think you don't mean that it MUST be applied in a
specific limited domain. Possibly "it MUST only be applied".

[GF]: Yes, we will revise this section as well.