Subject: SRH Issue 62

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Mar 2019 11:37:23 +0100

Hi,

Issue 62 read...

| 3.1 The various subsections contain a lot of "MUST" language. I didn't
find any
| statement of how a node should behave if it discovers a violation of any
of these.

Section 3.1 is now section 2.1

I checked through the section and it is generally good, but 2.1.1 still has 
      When present, a single Pad0 or PadN TLV MUST appear as the last
      TLV.  More than one Padding TLV MUST NOT appear in the SRH.  The
      Padding TLVs are used to align the SRH total length on the 8 octet
      boundary.
      Padding TLVs are ignored by a node processing the SRH TLV, even if
      more than one is present.
This is also the subject of another thread, and I personally don't see a
problem with "MUST NOT > 1" and "ignore > 1".
I find "MUST be last" a little harder to reconcile.
All in all, however, the inclusion of "ignore under all circumstances" seems
to suggest that the "MUST" and "MUST NOT" are unnecessary.
You could write...
      Padding TLVs are ignored by a node processing the SRH TLV, even if
      more than one is present.
      It is RECOMMENDED that implementations constructing an SRH minimize
      the number of Padding TLVs present, and use at most a single Pad0 or 
      PadN TLV placed as the last TLV in a sequence.

The use of "MUST" and "MUST NOT" to describe the presence of the two Padding
TLVs in the subsequent sections (2.1.1.1 and 2.1.1.2) would be similarly
affected.

Along the way, I searched for "MUST" a little more widely and found...

The 2119 boilerplate needs to move to section 1.1 (I think I mentioned this
the other day).

Section 2
   o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  The allocation
      and use of tag is outside the scope of this document.
There is a missing MAY associated with the SHOULD, and a conflict between
the SHOULD and the last sentence. I *still* cannot see how we can define a
field that a speculative meaning, some rules, and a complete delegation to
other documents.
It isn't even clear here whether packets tagged with zero are supposed to be
considered as in the same class or as in no class.
How about writing the following text instead?
   o  Tag: All packets with the same tag value are considered to be in 
      the same class or group of packets.  Assigning tag values to packets
      that have the properties allows them to be quickly identified and 
      subjected to the same treatment.  The tag value of zero means that
      a packet has not been assessed for tagging (i.e., is untagged).  Other
      tag values and processing rules for assigning tag values are outside 
      the scope of this document.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Mar 2019 11:57:52 +0100

Oh, I see that the discussion of the Tag field was on issue 61 that I raised
but somehow got marked as fixed.

Anyway, text below.

A

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Adrian Farrel
Sent: 31 March 2019 11:37
To: 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6MAN' <[email-masked]>
Subject: SRH Issue 62

Hi,

Issue 62 read...

Section 2

Thanks,
Adrian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------