Subject: Re: [PATCH v2 1/1] Documentation: networking: document ISO 15765-2:2016

From: Francesco Valla <[email-masked]>
Date: Tue, 16 Apr 2024 18:42:48 +0200

On Sun, Apr 14, 2024 at 10:21:33PM +0200, Oliver Hartkopp wrote:
> 
> 
> On 14.04.24 06:03, Vincent Mailhol wrote:
> 
> > 
> > This doesn't remove the fact that I think that this naming convention
> > is stupid because of the RAS syndrome, but I acknowledge that CAN CC
> > is now the official denomination and thus, that we should adopt it in
> > our documentation as well.
> > 
> 
> ;-)
> 
>

I honestly did not knwow the new CAN in Automation naming scheme. Will
keep the CAN-CC here. Thanks!

> > > > Add a space between ISO and the number. Also, update the year:
> > > > 
> > > >     ISO 15765-2:2024
> > > > 
> > > 
> > > Interesting! Didn't know there's already a new version.
> > > 
> > > Will check this out whether we really support ISO 15765-2:2024 ...
> > > 
> > > Do you have the standard at hand right now or should we leave this as
> > > ISO15765-2:2016 until we know?
> > 
> > I have access to the newer revisions. But I never really invested time
> > into reading that standard (neither the 2016 nor the 2024 versions).
> > 
> > Regardless, here is a verbatim extract from the Foreworld section of
> > ISO 15765-2:2024
> > 
> >    This fourth edition cancels and replaces the third edition (ISO
> >    15765-2:2016), which has been technically revised.
> > 
> >    The main changes are as follows:
> > 
> >      - restructured the document to achieve compatibility with OSI
> >        7-layers model;
> > 
> >      - introduced T_Data abstract service primitive interface to
> >        achieve compatibility with ISO 14229-2;
> > 
> >      - moved all transport layer protocol-related information to Clause 9;
> > 
> >      - clarification and editorial corrections
> > 
> 
> Yes, I've checked the release notes on the ISO website too.
> This really looks like editorial stuff that has nothing to do with the data
> protocol and its segmentation.
> 

The :2016 suffix is cited both here and inside the Kconfig. We can:
- keep the :2016 here and then update both the documentation and the
  Kconfig once the standard has been checked
- move to :2024 both here and inside the Kconfig
- drop the :2016 from everywhere (leaving only ISO 15765) and move to
  ISO 15765:2024 only inside the "Specifications used" paragraph

What do you think? Shall the modifications to the Kconfig be done as part of
this series?

Best regards,
Francesco Valla