Subject: [Teas] Terminology review of draft-ietf-teas-actn-requirements

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 30 Nov 2016 11:37:24 -0000

As promised, I have reviewed draft-ietf-teas-actn-requirements for terminology
and consistency with RFC 7926.

Actually, I had no issues with the use of terminology in this document. There is
a terminology dependency on the Framework draft which:
- may seem unnatural (having requirements depend on the architecture that
   satisfies the requirements)
- means that the Framework needs to be a normative reference.

I tried to understand the purpose of the document, and the best value I could
find was in section 4: that section seems to tell me what function needs to be
supported by the two interfaces. Section 2 was also somewhat useful in that it
seems to say what the purpose and value of ACTN is, however, I couldn't really
understand what that is doing in this document rather than in the Framework: it
seems to be trying to justify ACTN rather than impose requirements on something
- perhaps it imposes requirements on the developers of the solution
architecture, but if so it is a bit self-referential.

Section 3, seems to just repeat section 2 (but viewed from a different angle).
Section 3.1 doesn't add much except a type classifier for requirements. So I
suggest:
- move the definitions of types of requirement from 3.1 to
   the top of 2
- split 2 into subsections for the two types of requirement
   reflecting the classification in 3.1
- delete the whole of 3

In section 4, about half of the interface requirements are accompanied by little
quotes (such as "Give me a VN?"). This is really useful and should be extended
to all of the interface requirements.

Also in section 4 it is often unclear what the bullets mean under each
requirement. I think these are parameters of qualifications of the
request/response at the interface, but it would help to make this clear.

I have sent the authors a more detailed set of changes, typos, clarifications,
and suggestions in a Word file which I won't bother the list with.

Cheers,
Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

---

From: Leeyoung <[email-masked]>
Date: Wed, 30 Nov 2016 19:48:41 +0000

Hi Adrian,

Thank you so much for your careful and very useful review of this document. We will try to address your comments/suggestions and have the WG know all the changes of the document before publishing the revision. Please see in-line for my comment. 

Best regards,
Young (on behalf of co-authors and contributors)

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, November 30, 2016 5:37 AM
To: [email-masked]
Subject: [Teas] Terminology review of draft-ietf-teas-actn-requirements

As promised, I have reviewed draft-ietf-teas-actn-requirements for terminology and consistency with RFC 7926.

Actually, I had no issues with the use of terminology in this document. There is a terminology dependency on the Framework draft which:
- may seem unnatural (having requirements depend on the architecture that
   satisfies the requirements)
- means that the Framework needs to be a normative reference.

YOUNG>> OK. 

I tried to understand the purpose of the document, and the best value I could find was in section 4: that section seems to tell me what function needs to be supported by the two interfaces. Section 2 was also somewhat useful in that it seems to say what the purpose and value of ACTN is, however, I couldn't really understand what that is doing in this document rather than in the Framework: it seems to be trying to justify ACTN rather than impose requirements on something
- perhaps it imposes requirements on the developers of the solution architecture, but if so it is a bit self-referential.

YOUNG>> I think the part of the reasons why you feel this way is that many operators' use-cases had their multi-domain architecture in mind. In a sense, each use-case that was referenced and presented in the ACTN BOF back in Toronto (IETF 90) had this very particular context in mind and thus the requirements appeared to be self-referential based on their use-case. This requirement document tried to come up with a set of common requirements from each use-case referenced.  

YOUNG>> Agreed. 

In section 4, about half of the interface requirements are accompanied by little quotes (such as "Give me a VN?"). This is really useful and should be extended to all of the interface requirements.

YOUNG>> Great suggestion. Will try to do that. 

Also in section 4 it is often unclear what the bullets mean under each requirement. I think these are parameters of qualifications of the request/response at the interface, but it would help to make this clear.

YOUNG>> Agreed. 

I have sent the authors a more detailed set of changes, typos, clarifications, and suggestions in a Word file which I won't bother the list with.

YOUNG>> Received. Thanks.  

Cheers,
Adrian

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas