TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130													     R2-2503703
St Julian’s, Malta, 19-23 May 2025									  									  
Agenda item:	2.5
Source:	Apple
Title:	On specification file formats and workflows
Document for:	Discussion and Decision

1	

TDoc file conclusion not found

3GPP TSG-RAN WG2 Meeting #130	Tdoc R2-2504187
St Julian’s, Malta, May 19 – 23, 2025

Agenda:	2.5
Source:	Ericsson
Title:	Further aspects on improvements to specification handling
Document for:	Discussion, Decision

1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	CR workflow is the main aspect to be improved.
Observation 2	The adoption of more appropriate file formats and tools would simplify the delegates’ daily work without changing the 3GPP’s procedures.
Observation 3	Git allows splitting specifications into smaller files and to choose file types (e.g. Markdown, ASN, JSON, …) that suit the specific purpose..
Observation 4	There are multiple ways of working with offline files for internal preparation and use in the Git universe. Hence the use of e.g. the Gitlab online tool may be an option for those interested but not mandatory.
Observation 5	If needed, it is possible to create Word-documents of the Markdown specifications using open and free tools such as Pandoc.

3GPP TSG-RAN WG2 Meeting #130	R2-2504415
St. Julian’s, Malta, 19 – 23 May 2025	

Agenda item:	8.0
Source:	Nokia (Rapporteur)
Title:	Report of [POST129bis][002][ASN.1 review] Process improvements
WID/SID:	General - Release 19
Document for:	Discussion and Decision
1	

Conclusion
The following summarize the discussion.
Summary 1: This question was about if the review file should be split and how. Out of 7 replies, 5 companies prefer to split by section, and 2 prefer to split by WI. Two companies also supported storing the comments in a separate file or files, which is also discussed in a subsequent question. 
Summary 2: This question asked about which of five enhancements should be considered, including reducing the comment template, using a pointer to a table of comments, enforcing rules about similar comments, discussing complex issues externally to the review, and maintaining comments in a separate file. Seven companies replied to this question. 6 of the companies support storing comments in a table whose rows are pointed to by a pointer in the bubble comment. 4 of the companies were in support of reducing the comment template to increase readability. Some argued that at least the WI and RIL number should be mandatory. It seems that we could compromise in the middle and support a small comment template that includes the WI and RIL number and a pointer to a comment in a table. 
Summary 3: This question was about whether to impose a time limit for checking out the review file. Seven companies answered this question. Four were in favour of imposing a time limit on checking out the review file, but it was pointed out that a limit of 1 hour already exists. Those not in favour of imposing a time limit argued that with the changes to the process, long checkout times won’t be a problem. Therefore, nothing is proposed.
Summary 4: This question was about whether or not to develop a tool to automate the check-in/check-out process. 3 companies answered yes to this question, and 2 answered no. Without strong support in either direction, nothing is proposed.
Summary 5: This question was about whether or not to formalize the pre-specification freeze review process, e.g., implementing a RIL process on WI-specific running CRs. 5 companies answered this question. 2 companies were in support of formalizing the pre-specification freeze review process, while 2 were against, and 1 was neutral. It was noted that the running CRs can already be used for advanced review per WI. Without a strong view in either direction, nothing is proposed.
The following were proposed.
Proposal 1: For the ASN.1 review, split the review file into smaller files. FFS where to split the file and how many times.
Proposal 2: Reduce the comment template to the WI and RIL number and include a pointer to a comment in a table.

3GPP TSG-RAN WG2 Meeting #130						R2-2504448
St Julian’s, Malta, 19th - 23rd May 2025

Agenda item:	2.5
Source:	Samsung
Title:	Markdown for CRs – Gaps and Possible Solutions
Document for:	Discussion and Decision

Summary
A number of gaps between Markdown + gitlab + other tools exist. Some have work arounds that require some getting used to and reduced expectations. Other gaps have no known solutions yet.
Several observations are summarized below. 
Observation #1: Markdown supports most of styles in 3GPP document formats except EN, NO, EX, TF, TH. 
Observation #2: Tables in Markdown are expressed in one of two ways. Either each row in the table is written in a single paragraph, or a ‘grid table’ extension of Markdown is used. The first approach is very difficult to read, the second is very difficult to write.
Observation #3: Use of Markdown notation for symbols/characters could make text hard to read for those who do not know Markdown well.
Observation #4: it is possible to embed images and procedures (flow diagram) in Markdown. There is no simple tool available for free form figure content. 
Observation #5: Disagregated content can be resolved with conventions and current capabilities of git, gitlab, etc. for both on- and off-line work. This approach will add to the complexity to with CRs and specification text for delegates, as they will have to properly organize and use disaggregated content that today is aggregated in MS Word.
Observation #6: In Markdown + git + gitlab, only changes from two specific version are visualized and captured by the tools, while MS word can capture changes between multiple different versions, with diverse change mark coloring.
Observation #7: in situations where gitlab is not available (off-line work) it would be difficult or impossible to capture comments.
Observation #8: Working without WYSIWYG editing and reviewing requires learning and adjustments for users. Lack of WYSIWYG capabilities would make collaboration in live working groups sessions (editing documents live) very difficult or impossible.