Re: [Teas] Artart last call review of draft-ietf-teas-rfc3272bis-24

[Adrian Farrel <[e-mail]>]

Many thanks, Rich.

In line.

All changes are in the buffer waiting for the gates to re-open on the 24th.

Cheers,
Adrian

> Sorry this is a day late.

Not a problem, and the usefulness of the review far outweighs the timing.

> I found section 1.1 a little hard to follow.  I'm not sure why, and
> I have no recommendations to make.

Hmmm. Yes, it is probably a bit "academic" or didactic in its approach. Maybe it is also 20 years stilted? If I read it out loud, I can hear the original author's voice 😊

That said, short of throwing it all out and rewriting it, I don't see an easy fix.

> Consider adding definitions of "ingress node" and "egress node" to 1.4

Consider it.

(And made the additions.)

> Sec 2.1, maybe change the first sentence to add "...includes the following
> sub-contexts:"

Yup

> "the ability of the network administrators to translate policies into network
> configurations."  Nice to see the human aspect mentioned.

We aim to please.

> Sec 2.3, "A network-wide view of the topology is also a must for offline
> planning" Presumably not the WHOLE network; maybe add clarification?

Oh!
Well: when is a network not a network?
When we came up with, "The Internet is a network of networks," we were being very clever and setting ourselves up for confusion.
Actually, it was for this reason that the PCE work started talking about a "network domain" or more loosely a "domain" [RFC4655]

So, I think that the text, as written, is correct, but could be clarified. The point is that to achieve correct offline planning across a network, or some part of a network, there needs to be a view of the whole of that network or that part of the network. Changing the text as:
OLD
   A network-wide view of the
   topology is also a must for offline planning.
NEW
   Offline planning requires a full view of the topology of
   the network or partial network that is being planned.
END

> Sec 4.1, do you need/want definitions or references for STT and ALB methods?

Yeah, references are good.
STT is RFC 6601
ALB is ITU-T E.360.1 

> Sec 5.1.2.3, To a customer, a slice looks like ... "with additional information
> about the level of service required between endpoints"  s/required/provided/ ?

No, this is "required". I mean, it should also be "provided": but the customer asks for the SLA and is hopeful that it will be delivered.
But this can be polished as:
OLD
   From a
   customer's perspective an IETF Network Slice looks like a VPN
   connectivity matrix with additional information about the level of
   service required between endpoints.
NEW
   From a
   customer's perspective, an IETF Network Slice looks like a VPN
   connectivity matrix with additional information about the level of
   service that the customer requires between the endpoints.
END

> Sec 5.1.3.1.1 typo's "Exampls" and "netrock"

Ack

> Sec 5.1.3.12 space before colon and while you're there, maybe s/;/, or/  And
> the "four types" described should be an unnumbered list or some such.

Ack

> Sec 6, I was surprised ...

Just trying to keep you awake.

> ... to see the definitions of functional/non-functional be
> in a different order from the sections that followed. Maybe a sentence at the
> end explaining why. "This document first summarizes the non-functional
> requirements, and covers the functional requirements in the following
> subsections."

Something like that included.

> In 6.1, is the ordering of attributes arbitrary? Could/should it be made
> alphabetical?

Yeah, I *think* it is arbitrary. That is, I can't recall any discussion of why they are in this order.

> In 6.5, typo "conforma"

Ack

> In 6.6.2, should "1+1" be "1:1" ? Apparently not, since 1+1 is not the same as
> 1:1  This should be mentioned.

Some clarity added.

> In 6.7, "Networks are often arranged in layers"  Should arranged by
> implemented?  What about Ogres (a little Shrek Joke,
> https://youtu.be/-FtCTW2rVFM?t=43)

I'm worried about how long you spent searching for that. Or, worse, that you already knew where to find it.

> Sec 8, "taken over a lot of" stuck out to me as rather informal.

"assumed"

> "Some other
> southbound interface"  What's a southbound interface?  

Oh, yes! One of my hot buttons and I missed it! Thanks.
Although the term is widely used, it is also not a functional description and is subjectively relative.
Replaced with "configuration and management"

> "such as a multi-national" add "enterprise"

Not so happy about this suggestion. 
The "such as" is aiming for a few indicative suggestions.
I fear that "enterprise" is often interpreted as the antithesis of a geographically widespread network. So adding it here may distract the reader.