1. 
   

   [Technical] The statement “all currently defined LI requirements in TS 33.126 remain applicable for 6G” is too strong without scoping, because TS 33.126 is written against specific 3GPP system assumptions (e.g., LI architecture, identifiers, service types) that may not map 1:1 to 6G features; at minimum it should qualify applicability “where relevant” and identify expected gaps.

   
   


2. 
   

   [Technical] The proposed normative “shall” text in TR 23.801-01 is problematic because TRs are typically informative/study documents; adding normative requirements in a TR risks process inconsistency and unclear compliance expectations (the text should be informative guidance or moved to a TS/requirements spec).

   
   


3. 
   

   [Technical] The proposed clause 4.2 insertion is vague (“all WTs and corresponding key issues”) and does not define what “taken into account” means (e.g., mandatory LI impact assessment, LI assumptions, or explicit LI-related outputs), so it is unlikely to drive actionable architecture work.

   
   


4. 
   

   [Technical] Referencing only TS 33.126 may be incomplete for 6G architecture studies, since LI requirements and related security/privacy constraints often span multiple specs (e.g., LI architecture, security architecture, identifiers); the LS should at least confirm whether additional normative references are expected or explicitly state TS 33.126 is the sole LI requirements anchor.

   
   


5. 
   

   [Technical] The LS asks groups to “inform SA3-LI of any issues … that may prevent compliance with TS 33.126” but provides no criteria or mechanism (e.g., trigger conditions, template, timeline aligned to architecture milestones), which risks late discovery—the opposite of the stated goal.

   
   


6. 
   

   [Technical] The request to add the same text to “other 6G TRs/TSs under development” is over-broad and may be inappropriate for TSs where LI is out of scope (e.g., radio/codec specs); it should identify specific target documents or at least limit to architecture/service requirements specs.

   
   


7. 
   

   [Technical] The LS does not identify any concrete 6G architectural topics likely to impact LI (e.g., new identifiers, distributed core functions, AI-native functions, new access types, slicing evolution), so recipient groups lack guidance on what to look for when “identifying potential topics.”

   
   


8. 
   

   [Editorial] The document mixes “6G systems” and “6G architecture development” without defining the scope (e.g., whether it refers to a specific 3GPP 6G study item/TR set), which makes the requested actions ambiguous across groups.

   
   


9. 
   

   [Editorial] The proposed text says “For more details on LI requirements, see TS 33.126” but does not specify version/release alignment; for early 6G studies, a stable reference (release-independent wording or explicit versioning) would avoid ambiguity as TS 33.126 evolves.

   
   


10. 
    

    [Editorial] The action list repeats “request clarification from SA3-LI” but does not provide a contact point, expected response handling, or whether clarifications should be captured as LS replies vs. change requests, reducing procedural clarity.

    
    

1) Technical Accuracy

1.1 Claim: “All currently defined LI requirements in TS 33.126 remain applicable for 6G”

• Questionable as stated / over-broad. TS 33.126 is written for the 3GPP system context of existing generations (notably EPS/5GS concepts, LI architecture assumptions, and interfaces). Declaring all requirements “remain applicable” to “6G” is not technically substantiated in the LS summary.


• Potential mismatch with future architecture: If 6G introduces new service-based paradigms, new trust models, new identifiers, new mobility anchoring, new slicing constructs, new exposure models, or new end-to-end security models, some TS 33.126 requirements may need:


• reinterpretation (mapping to new functions),


• scoping (which parts apply),


• or explicit exceptions/updates.


• Missing nuance: At minimum, the statement should be qualified as “remain applicable in principle” or “remain applicable subject to architectural mapping and gap analysis”.

1.2 Proposed normative text in TR 23.801-01 clause 4.2

• Normative “shall” in a TR is problematic. TRs are typically informative (study items). Introducing “shall” language in a TR is at least stylistically inconsistent and can be challenged procedurally. If the intent is to create a binding requirement, it should be:


• placed in a TS (normative specification), or


• rephrased in TR as “should be taken into account” / “is to be considered”.


• Reference correctness: “For more details on LI requirements, see TS 33.126.” is fine as a reference pointer, but it implicitly assumes TS 33.126 is the correct anchor for “6G LI requirements”. That may be premature if Rel-20/6G will require a new or revised LI requirements spec (e.g., a new TS/TR or a new versioned scope).

1.3 Scope ambiguity: “6G systems”

• 3GPP has not historically used “6G” as a formal system name in normative specs. If “6G” is being used as shorthand for “Rel-20 and beyond system”, the LS should align terminology with the official project naming used in SA2/SA3 (e.g., “next generation system”, “Rel-20 system”, etc.). Otherwise, the statement is technically ambiguous.

2) Completeness

2.1 Missing gap analysis / mapping

The LS asserts applicability but does not provide:

- a mapping of TS 33.126 requirements to candidate 6G architectural elements (new NFs, new interfaces, new identifiers),

- a list of known deltas where 6G directions may break assumptions (e.g., decentralization, new privacy features, new encryption defaults, new routing/anchoring changes),

- any risk register of LI-sensitive architectural choices.

Without this, the request is largely procedural (“please consider LI”) rather than technically actionable.

2.2 Missing references beyond TS 33.126

LI in 3GPP is not only TS 33.126. Depending on the topic, other relevant specs often include:

- TS 33.127 (handover interface aspects),

- TS 33.128 (retained data / related LI aspects, depending on scope),

- TS 33.108 (general security architecture; impacts LI feasibility),

- TS 23.501/23.502 (5GS architecture; for mapping precedent),

- ETSI LI handover standards (where applicable) for HI alignment.

If the intent is “requirements continuity”, the LS should at least acknowledge the broader LI spec set or explicitly justify why TS 33.126 alone is sufficient.

2.3 Missing discussion of jurisdictional/legal variability

The LS mentions “different jurisdictions and legal frameworks” but provides no concrete mechanism for handling:

- conflicting national requirements,

- privacy-by-design constraints,

- end-to-end encryption and lawful access boundaries,

- roaming and cross-border interception constraints.

A study-phase note is fine, but the LS could be strengthened by identifying which requirement categories are most sensitive.

3) Impact Assessment

3.1 On SA2 architecture work (TR 23.801-01 and other 6G studies)

• Low direct spec impact if kept as informative guidance, but high process impact: it forces SA2 to treat LI as a first-class constraint early.


• If implemented as normative “shall” text, it may create:


• procedural disputes (normative language in TR),


• unclear compliance criteria (“taken into account” is not testable),


• potential blocking comments in SA2 if LI requirements are perceived to constrain architectural innovation.

3.2 On SA4/SA6 (media, codecs, application enablers)

• The LS is broad and may cause scope creep: SA4/SA6 may not know what “take into account” means for media pipelines, E2EE media, conferencing, XR, etc.


• Potentially significant impact if 6G introduces more pervasive application-layer encryption or new media transport models; LI feasibility may become contentious.

3.3 On existing implementations

• If interpreted strictly (“all TS 33.126 requirements remain applicable”), vendors may be forced into backward-compatibility constraints that are not yet defined for 6G, potentially increasing complexity and cost.


• Risk of late-stage rework if LI is not properly mapped early—this is a valid concern, but the LS does not quantify or prioritize.

4) Feasibility

4.1 Feasibility of the requested action (adding text)

• Adding a reference sentence is feasible, but:


• normative phrasing in a TR is likely to be challenged,


• “for all WTs and corresponding key issues” is vague—SA2 may not be able to demonstrate compliance.

4.2 Feasibility of “TS 33.126 applies to 6G”

• Feasible only if SA3-LI commits to:


• producing a Rel-20 LI gap analysis against the emerging 6G architecture,


• updating TS 33.126 (or creating a new spec) with explicit mappings and any new requirements.
  
  Without that, feasibility is uncertain because “applicability” cannot be validated.

5) Weaknesses

5.1 Overly generic and non-testable requirement

• “shall be taken into account” is not measurable and can devolve into a checkbox statement with no engineering value.

5.2 No concrete technical issues identified

• The LS asks other groups to identify topics needing SA3-LI input, but SA3-LI does not provide an initial list of known LI-sensitive areas. This weakens the coordination request because it shifts all burden to recipients.

5.3 Potential procedural/specification-style issue

• Proposing normative text for a TR is a common point of contention. This weakens the likelihood of smooth acceptance in SA2/SA4/SA6.

5.4 Single-spec anchoring

• Anchoring solely on TS 33.126 risks missing other LI-related requirements/specs and creates an impression that LI is “solved” by a single document, which is rarely true in practice.

6) Suggestions for Improvement

6.1 Rephrase the proposed TR text to be appropriate for a study item

Replace normative “shall” with informative study wording, e.g.:

- “Lawful interception requirements should be considered for all WTs and corresponding key issues in this study. LI requirements are specified in TS 33.126 (and related LI specifications).”

Or:

- “This study is expected to assess implications on LI requirements (TS 33.126) and identify gaps.”

6.2 Provide an initial LI gap/risk checklist for 6G architecture

Include (even as an annex or companion note) a short list of architectural areas that typically impact LI, for example:

- identifiers and identity privacy (new SUPI-like concepts, pseudonyms),

- routing/anchoring changes (distributed UPF equivalents),

- service-based interfaces and exposure (APIs, eventing),

- slicing/tenant separation and lawful intercept per slice/tenant,

- E2EE and application-layer encryption defaults,

- edge computing and local breakout,

- non-3GPP access integration changes,

- roaming/inter-PLMN interception support.

This makes the LS actionable and reduces ambiguity for SA2/SA4/SA6.

6.3 Clarify what “applicable” means

Add a statement such as:

- “TS 33.126 requirements remain applicable as baseline principles, subject to mapping to the 6G architecture and identification of any necessary enhancements or exceptions.”

This avoids an absolute claim that may be technically incorrect later.

6.4 Expand references or explicitly scope them

Either:

- reference the broader LI spec set (33.126/33.127/33.128 as appropriate), or

- explicitly state: “TS 33.126 is the primary requirements baseline; additional LI specs may apply depending on architecture.”

6.5 Define a concrete coordination mechanism

Instead of “send LSs if needed”, propose:

- a standing agenda item / joint workshop between SA2 and SA3-LI at key milestones,

- a timeline aligned with TR 23.801-01 deliverables,

- a commitment from SA3-LI to deliver a Rel-20 LI gap analysis report by a specific stage.

6.6 Avoid “6G” terminology if not formally adopted

Align with the official naming used in the target TRs/TSs (e.g., “Rel-20 system”, “next generation system”) to prevent editorial and procedural pushback.

Bottom line

The intent (early LI consideration) is reasonable, but the LS as summarized is too absolute, too generic, and procedurally fragile (normative “shall” in a TR). It would be significantly strengthened by (i) rewording to study-appropriate language, (ii) providing an initial LI-sensitive topic list and gap-analysis plan, and (iii) clarifying the meaning and limits of “TS 33.126 applicability” for a future 6G/Rel-20 architecture.