Re: [Teas] [mpls] New Version Notification for draft-busizheng-teas-yang-te-mpls-topology-05.txt

[tom petch <[e-mail]>]

From: Italo Busi <[e-mail]>
Sent: 12 October 2023 17:30

Hi Tom,

What about the following abstract?

"This document describes a YANG data model for MPLS-TE network topologies."

With the required acronyms' expansion it should become:

" This document describes a YANG data model for Multiprotocol Label Switching (MPLS) Traffic Engineering (MPLS-TE) network topologies."

Italo

<tp>
I still prefer a more expansive approach e.g.

" This document describes a YANG data model for the <management¦monitoring¦construction¦...> of the topology of Traffic Engineered  Multiprotocol Label Switching (MPLS) networks."

Those stacked nouns I find hard to interpret although I recognise that it is the norm in some languages. Also I like verbs - manage, operate, configure and so on.

Tom Petch


> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: martedì 10 ottobre 2023 13:53
> To: tom petch <[e-mail]>; Italo Busi <[e-mail]>;
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls] [Teas] New Version Notification for draft-busizheng-teas-
> yang-te-mpls-topology-05.txt
>
>
> From: mpls <[e-mail]> on behalf of Adrian Farrel
> <[e-mail]>
> Sent: 10 October 2023 11:47
> Thanks Tom.
>
> > Adrian may be happy but that mightn be a reflection on the vast range
> > of knowledge that Adrian has but which not all readers may possess -
> > this one doesn't.
>
> Vast, maybe. Relevant, not so much.
>
> I think I am more relaxed on what becomes a WG I-D. That is:
> - is it a topic the WG wants to work on
> - is this a reasonable starting point
>
> Obviously (?) if a fairly active WG participant (you) cannot easily discern the
> point of the work, then answering the first question is hard.
>
> It is not an uncommon problem that authors find themselves too close to the
> problem to (feel the need to) explain it. It is also the case that "we" are pretty
> poor at writing Abstracts, often scribbling them at day 1 and then never
> updating them. It is good to call the authors out on that, especially (as you did)
> with specific questions that need to be addressed. I'm sure the authors will
> want to clarify the purpose of the document by adding text to the Abstract
> and Introduction.
>
> <tp>
> Some decades ago, I adopted a top-down approach, not just when creating
> software but in anything of an engineering nature.  With I-Ds that means I
> start with the Abstract and work down to Introduction and so on.  I find that
> makes my output more coherent.
>
> It seems to me that the IETF is more bottom-up and while that works as a
> management style I find it less useful when it comes to documents.
>
> Thus for me this I-D is - I think -
> Transport Network
> Traffic Engineering
> MPLS data plane
> Topology
> YANG model
> and while I might move YANG model up or down I would not change the rest.
> This structure for me is what the Abstract lacks.  In German it might be one
> portmanteau word of 42 letters but not in english (or American).
>
> I had just been looking at
> draft-ietf-ccamp-eth-client-te-topo-yang
> and while I am not a fan of the draft name and strongly averse to the change
> thereof, yet the Introduction is just what I want to see.  And I think that that
> may be a more general truth when setting CCAMP against MPLS.
>
> Tom Petch
>
> Ciao,
> Adrian
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls