Re: [Teas] Resolving the remaining terminology issue with "IETF Network Slice"

[tom petch <[e-mail]>]

From: John Scudder <[e-mail]>
Sent: 14 September 2023 18:42

Hi All,

I get Tom’s point that if you read the Normatiive/Informative criteria literally, “RFC XXXX Network Slice” might be said to require a Normative reference. I would argue, however, that “IETF Network Slice” would do so equally, though, since neither one is fully and unambiguously self-explanatory. So nothing has really changed as a result of the v25 revisions.

As Deborah points out, the downref registry is a thing that exists, so the modest hoop of calling out the downref during IETF Last Call needs only be jumped through once, after which the document can be (and will be!) added to the downref registry. Once it’s on the registry I believe the tooling takes care of checking automatically. So the effort, while nonzero, is pretty modest, manageable, and effectively one-time. The effort to move the framework to PS would be substantially greater and more importantly, not really justified IMO.

<tp>
John, Deborah

Thanks for the responses.

I was having two left field thoughts.  One is the ongoing discussion about re-organising Areas. the subtext of which is ADs have too much to do; I often think of how the work could be reduced or at least not increased, is there anthing I can do (well apart from not making posts such as this).

The other was the adoption of the LSR I-D about prefix unavailable where it seemed to take manual intervention by the Chair to link that pre- and post- adoption I-Ds which I see as particularly important in that case.

I do not know what the tooling does and do not know where it is specified.  Like the Windows system I use, I stumble across changes which may or may not suit me.

So I have seen a number of cases where the Last Call has been reissued because the initial announcement lacked required details.  Historically at least some of those have been the lack of a Downref so while the exercise of adding the RFC to the Downref registry is a one-off, I am not sure that subsequent Last Calls will pick it up.  Time will tell.

There is also Deborah's point about other SDOs doing things differently and wanting their processes to apply to IETF documents.  I note the liaison to 3GPP.  I do not know their take on Normative is but another left field thought is a recent post to rfc-i where the author is converting to RFC Style and expects to indicate section by section what is Normative what is not - my response was forget it, accept that RFC Style is RFC Style and the document will need changing to sit..

Tom Petch

Thanks,

—John

> On Sep 14, 2023, at 12:15 PM, BRUNGARD, DEBORAH A <[e-mail]> wrote:
>
> Hi Tom,
>
> The point you raised that as a result of IESG review, it should be considered if this document would be better as “PS”, is very relevant. I agree with you but also am aware of the hoops that would need to be jumped and so it is a difficult decision (I am happy that I am no longer the one that needs to decide).
>
>       • Downrefs are clunky but process-wise a bit easier as currently just need to be registered on a list. Though workload does require constantly checking if it is listed.
>       • Status change at this time would require returning to the working group and approving as PS. And then the risk is that the IESG will not accept. It’s a difficult discussion, Informational is by some not highly regarded as “useful”, but PS for a non-protocol document is a high jump.
>
> There are examples of PS, one of the most recent was the detnet architecture:
> https://datatracker.ietf.org/doc/rfc8655/
>
> If you read the IESG comments, you will see the doubt on it being PS. If scan down and look at my reply to Ben, it was based on the need to be a reference for future documents and the cross-SDO interest:
>
> https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-detnet-architecture%22
>
> For this TEAS document, I think the same rationale holds. But to jump thru the hoops may be too much. Hopefully the requirement to name the slice RFCXXXX is only necessary in the introduction and not with every instance of “network slice” in other documents.
>
> Deborah
>
>
> From: Teas <[e-mail]> On Behalf Of tom petch
> Sent: Thursday, September 14, 2023 11:36 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [Teas] Resolving the remaining terminology issue with "IETF Network Slice"
> ZjQcmQRYFpfptBannerEnd
> From: Teas <[e-mail]> on behalf of Adrian Farrel <[e-mail]>
> Sent: 14 September 2023 15:26
>
> Hi TEAS,
>
> If you've been following closely, you'll have seen that the IESG had some
> misgivings about our use of the term "IETF Network Slice."
>
> I think we managed to explain to the IESG why the term was necessary in
> draft-ietf-teas-ietf-network-slices specifically to distinguish our work
> from other aspects of the more general 3gpp concept of network slicing, and
> to avoid having to use the term "transport network slice" which would
> undoubtedly be confusing within the IETF.
>
> However, other documents that reference the framework do not need to use
> "IETF Network Slice." Or they won't need to once the framework is published
> as an RFC because they can reference the RFC to give the context. The
> proposal, therefore is:
> 1.      To strengthen the text in the framework about why the term is needed
> and used in that document
> 2.      To state in the framework that the term is only for use within the
> framework document
> 3.      To say in the framework that all referencing documents should use
> the term "RFC XXXX Network Slice" (where XXXX is the number assigned to the
> framework when published as an RFC - RFC Editor Note will cause XXXX to be
> replaced with the actual number).
> 4.      To update all documents in progress to use the term "RFC XXXX
> Network Slice" with RFC Editor Note to request that XXXX is replaced with
> the number assigned to the framework draft when published as an RFC.
> 5.      When RFC XXXX is published, update all documents not already in the
> RFC Editor Queue with the actual number.
>
> <tp>
>
> Ah yes, let's increase the workload of the IESG!
>
> To make sense of the referencing documents, readers will have to go to RFC XXXX.  This I-D is Informational.  Therefore these references  will be Downrefs which will increase the workload of the IESG.
>
> I realise the some ADs have criteria for making a document Standards Track that architecture documents and such like will never qualify for because of a lack of a protocol definition therein.
>
> Me, I am a pragmatic engineer.  If a document has to be referenced Normatively, then it needs to be Standards Track no matter how little protocol there is in it!
>
> Clunky, yes.
>
> Tom Petch
>
> This is a little clunky, but it seems the best way to address the IESG
> concerns and, although it is some work for everyone, it is not a big deal.
>
> I don't want to rehearse the discussions already had with the IESG (although
> I don't suppose I can stop you if you want to re-open them), but I wanted to
> give you this heads-up before I post the updated version of the framework.
>
> Cheers,
> Adrian
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!BhdT!luxnjYmaUQhcgdn6Yr8uaAfgqrxbpPpqB3RqcynyaaJE4tdhGwQOkUa0J5z4nq8WsRd3e7Bfq1nqBqs$
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!BhdT!luxnjYmaUQhcgdn6Yr8uaAfgqrxbpPpqB3RqcynyaaJE4tdhGwQOkUa0J5z4nq8WsRd3e7Bfq1nqBqs$
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!FaGvYT_mpCDqqF9yh4juFfOmMlhZGls8NIJDCwZO6UvrmXHIGvK7faW1dEDEgMZOhSZhW78x3A$