Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 11 Mar 2021 17:37:26 +0000

CCAMP,

the IPR declaration collection has been successfully completed before the IETF week and we can move to the next step.

This starts a 2 weeks working group last call on draft-ietf-ccamp-transport-nbi-app-statement-12
The last call ends on Thursday March 25th. Please send you comments to the CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/history/
Please note that no IPR has been disclosed against this document.

If interested, please volunteer to be the shepherd of the draft.

Thanks

Daniele & Fatai

---

From: Italo Busi <[email-masked]>
Date: Wed, 24 Mar 2021 18:34:09 +0000

Hi all,

I think the document is ready for publication

There is a note that calls for some text update which can be done during the WG LC based on the discussion we have had with the authors of [TE-TUNNEL] and [TE-TUTORIAL] drafts:

https://github.com/tsaad-dev/te/issues/59

I would propose the following change to the draft:

OLD

   TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented
   service provided by a layer network of delivery of a client's data
   between source and destination tunnel termination points.

   TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a
   multi-domain TE tunnel that spans.

   TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access
   link or inter-domain link by which a multi-domain TE tunnel enters
   or exits a given network domain.

   Note - The three definitions above are currently in [TE-TUTORIAL]
   but it is expected that they will be moved to [TE-TUNNEL]. When this
   happens, the reference will be updated and the [TE-TUTORIAL]
   reference will be downgraded to Informative.

NEW

   TE Tunnel: As defined in [TE-TUNNEL], it is a connection-oriented
   service provided by a layer network of delivery of a client's data
   between source and destination tunnel termination points. See also
   [TE-TUTORIAL].

   TE Tunnel Segment: As defined in [TE-TUNNEL], it is a part of a
   multi-domain TE tunnel that spans. See also [TE-TUTORIAL].

   TE Tunnel Hand-off: It is an access link or inter-domain link by
   which a multi-domain TE tunnel enters or exits a given network
   domain. See also [TE-TUTORIAL].

Italo (as co-editor)

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: giovedì 11 marzo 2021 18:37
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

---

From: <[email-masked]>
Date: Wed, 24 Mar 2021 18:41:58 -0000

Thanks Italo, I agree with the update. 

With the new definitions I think the document is ready for publication.

BR, Dan. 

From: CCAMP <[email-masked]> On Behalf Of Italo Busi
Sent: 24 March 2021 18:34
To: 'Daniele Ceccarelli' <[email-masked]>; CCAMP
<[email-masked]>
Subject: Re: [CCAMP] WG last call on
draft-ietf-ccamp-transport-nbi-app-statement-12

Hi all,

There is a note that calls for some text update which can be done during the
WG LC based on the discussion we have had with the authors of [TE-TUNNEL]
and [TE-TUTORIAL] drafts:

OLD

NEW 

   [TE-TUTORIAL].

Italo (as co-editor)

From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: giovedì 11 marzo 2021 18:37
To: CCAMP <[email-masked] <mailto:[email-masked]> >
Subject: [CCAMP] WG last call on
draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

the IPR declaration collection has been successfully completed before the
IETF week and we can move to the next step.

This starts a 2 weeks working group last call on
draft-ietf-ccamp-transport-nbi-app-statement-12

The last call ends on Thursday March 25th. Please send you comments to the
CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected
and can be found in the history of the document
https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statemen
t/history/

 

Thanks

Daniele & Fatai

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 24 Mar 2021 18:55:51 +0000

Hi Daniele, Fatai, CCAMPers,
I read the document , I know it since I was part of the DT, and I consider it a very important analysis based on use cases of the applicability of IETF models, showing the level of maturity of many of them.  The document is ready for publication.

Thanks
Sergio

From: CCAMP <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: Thursday, March 11, 2021 6:37 PM
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 24 Mar 2021 19:12:05 +0000

Hi Italo,
Only one comment: the TE tunnel hand-off in Tutorial draft, is defined  for the "point",
I mean :
TE tunnel hand-off point - an access link or inter-domain link by which a multi-domain TE tunnel enters or exits a given network domain, in conjunction with a layer network resource (such as a wavelength channel or ODUk container) allocated on the access/inter-domain link for the TE tunnel

For the rest I have no objection.

Thanks
Sergio

From: CCAMP <[email-masked]> On Behalf Of Italo Busi
Sent: Wednesday, March 24, 2021 7:34 PM
To: 'Daniele Ceccarelli' <[email-masked]>; CCAMP <[email-masked]>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Hi all,

OLD

NEW

Italo (as co-editor)

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: giovedì 11 marzo 2021 18:37
To: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 24 Mar 2021 20:26:01 +0000

Hi all,

I was a member of the design team, too. Given the complexity of the IETF models, I agree with Sergio that analyzing use cases is important. Specifically, worked-through examples help a lot, and it makes sense to document them. I did not find any significant issues in the latest version.

Best regards

Michael

From: CCAMP <[email-masked]> On Behalf Of Belotti, Sergio (Nokia - IT/Vimercate)
Sent: Wednesday, March 24, 2021 7:56 PM
To: Daniele Ceccarelli <daniele.ceccarelli=[email-masked]>; CCAMP <[email-masked]>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Thanks
Sergio

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniele Ceccarelli
Sent: Thursday, March 11, 2021 6:37 PM
To: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

---

From: Dieter Beller <[email-masked]>
Date: Thu, 25 Mar 2021 09:53:20 +0100

no further LC comments from my side.

I support moving the draft forward and start the publication process.

Thanks,
Dieter

On 11.03.2021 18:37, Daniele Ceccarelli wrote:
>
> CCAMP,
>
> the IPR declaration collection has been successfully completed before 
> the IETF week and we can move to the next step.
>
> This starts a *2 weeks working group last call* on 
> The last call ends on *Thursday March 25^th *. Please send you 
> comments to the CCAMP mailing list.
>
> All the IPR declarations from authors and contributors have been 
> collected and can be found in the history of the document 
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/history/ 
> <https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/history/>
>
> If interested, please volunteer to be the *shepherd* of the draft.
>
> Thanks
>
> Daniele & Fatai
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Ricard Vilalta <[email-masked]>
Date: Thu, 25 Mar 2021 11:06:19 +0100

I also support moving the draft forward. Looking forward to its publication.
Thanks,
Ricard

On Thu, Mar 25, 2021 at 9:53 AM Dieter Beller <[email-masked]>
wrote:

> The last call ends on *Thursday March 25th*. Please send you comments to
> the CCAMP mailing list.
>
>
>
> CCAMP mailing [email-masked]://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Aihua Guo <[email-masked]>
Date: Thu, 25 Mar 2021 11:02:32 -0400

Hi All,

I fully support the publication of this draft and I have no further
comments on the content. The examples within this draft have been more than
helpful to clear the confusion of using the models to support transport
network use cases, given the complexity that it derives from the base TE
models. Some of those examples came out of past interop experiences and
were validated against real use cases.

Thanks,
Aihua

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 25 Mar 2021 17:41:41 +0000

WG,

The poll is now conclude and we will proceed with the request for publication.

The changes suggested by Italo and Sergio do not impact the content of the document and will be addressed as part of the next rounds of review.

Thanks,
Daniele

From: CCAMP <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: den 11 mars 2021 18:37
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

---

From: Victor Lopez <[email-masked]>
Date: Thu, 25 Mar 2021 17:42:52 +0000

Dear all,

I believe the document is ready for publication.

Cheers

Victor
________________________________
De: CCAMP <[email-masked]> en nombre de Daniele Ceccarelli <daniele.ceccarelli=[email-masked]>
Enviado: jueves, 11 de marzo de 2021 18:37
Para: CCAMP <[email-masked]>
Asunto: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

Thanks

Daniele & Fatai

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Mar 2021 22:56:24 -0000

Hi,

I see Daniele got excited and requested publication, but it seems that it is
still 25/3 where I live. Sorry my review is right at the deadline, but it's
a long document.

It's nice to see guidance on using IETF technology. Particularly useful when
the ingredients include a list of YANG models. So I support publication of
this document.

I did find it a hard read and confess to not having checked the JSON
examples (55 pages were quite enough for me!).  Along the way I collected a
few minor issues and whole host of nits.

Best,

Adrian

== Minor ==

You need to stop using legitimate IP addresses and switch to using

documentation ranges. idnits does point this out.

Suitable ranges are described in RFC 5737.

---

2.

   Connectivity Service: A service, or connectivity service, in the

   context of this document can be considered as some form of

   connectivity service between customer sites across the network

   operator's network [RFC8309].

That's a bit broken. "A connectivity service is some form of

connectivity service." :-)

---

2.

At this point in the publication cycle it is close to time to make a 

choice on this point.

---

3.1 needs to explain the meaning of curly brackets {} in the notation.

---

5.4

   The notification mechanisms are protocol-dependent. It is assumed

   that the RESTCONF protocol, defined in [RFC8040], is used at the

   MPIs mentioned in this document.

Do you mean that the notification mechanisms are dependent on the 

data plane technology, or on the protocol used to report the 

notifications? If the latter (which seems most likely) then the first

sentence is self-evident, but (worse) it seems to conflict with the

second sentence that constrains use to RESTCONF.

---

== Nits ==

General point:

- noun "a setup"

- verb "to set up"

I called out some of these, but probably missed loads.

---

The Abstract should be the first thing in the document.

---

Abstract

OLD

   This document provides an analysis of the applicability of the YANG

   models defined by the IETF (Traffic Engineering Architecture and

   Signaling (TEAS) moreover, Common Control and Measurement Plane

   (CCAMP) WGs in particular) to support ODU transit services,

   Transparent client services and EPL/EVPL Ethernet services over OTN

   single and multi-domain network scenarios.

NEW

   This document provides an analysis of the applicability of the YANG

   models defined by the IETF (in particular in the Traffic Engineering

   Architecture and Signaling (TEAS) and Common Control and Measurement

   Plane (CCAMP) working groups) to support ODU transit services,

   transparent client services, and Ethernet Private Line/Ethernet

   Virtual Private Line (EPL/EVPL) services over Optical Transport

   Network (OTN) in single and multi-domain network scenarios.

END

---

1.

   Transport network domains, including Optical Transport Network (OTN)

   and Wavelength Division Multiplexing (WDM) networks, are typically

   deployed based on a single vendor or technology platforms.

s/technology platforms /on a single technology platform/

---

1.

s/are critical/is critical/

---

1.

OLD

   This document examines the applicability of the YANG models being

   defined by IETF (Traffic Engineering Architecture and Signaling

   (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in

   particular) to support Optical Transport Networks (OTN) single and

   multi-domain scenarios.

NEW

   This document examines the applicability of the YANG models defined

   by the IETF (in particular in the Traffic Engineering Architecture

   and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP)

   working groups) to support OTN in single and multi-domain network

   scenarios.

END

---

1.1

s/based on the/based on the Framework for/

s/called MDSC-PNC Interface/called the MDSC-PNC Interface/

s/called CNC-MDSC Interface/called the CNC-MDSC Interface/

---

1.1

Expand "ODU" and "EPL/EVPL" on first use

---

2.

s/as an edge on TE graph/as an edge on the TE graph/

s/layer network of delivery of/layer network for delivery of/

---

2.

Expand FC and STM-n on first use

---

3.2

s/3.2. JSON code/3.2. JSON Code/

OLD

(TEAS and CCAMP WG in particular)

NEW

(in particular, the TEAS and CCAMP working groups)

END

s/by an "-"/by a "-"/

s/have been instead found/have been found/

s/some numbering scheme/a numbering scheme/

---

The numbering of the switches in Figure 1 is slightly confused.

It looks like you started numbering them at S1 through S8 in domain 1,

and then moved on to start at S11 in domain 2 but had to go up to S21

because of the number of switches. And then domain 3 starts at S31.

It's not important. Just odd.

---

4.1

s/MDSC control the/MDSC controls the/

---

4.1

   The split of functionality at the MPI in the ACTN architecture

   between the MDSC (multi-domain controller) and the PNCs (domain

   controllers)

You probably don't need to expand MDSC and PNC again.

---

4.1 and 4.2 mention MPI1, MPI2 etc....

Figure 2 does not number the MPIs. Perhaps it should.

---

4.2

s/PNcs/PNCs/

---

4.3

Please expand ETH and SDH on first use

---

4.3.1

   When a 10Gb IP link between R1 and R8 is needed

Do you mean "connection"? Or even "connectivity service".

Similar in later sections.

---

4.3.1

s/CMI,the/CMI, the/

s/to setup/to set up/

---

s/4.4. Multi-function Access Links/4.4. Multi-Function Access Links/

---

OLD

4.5.1. Linear Protection (end-to-end)

NEW

4.5.1. Linear Protection (End-to-End)

END

---

4.5.2

s/MDSC can request/the MDSC can request/

s/MDSC can also request/the MDSC can also request/ (twice)

---

4.6

OLD

   To realize the topology update, service update and restoration

   function, following notification types should be supported:

NEW

   To realize the three functions of topology update, service update,

   and restoration, the following notification types need to be

   supported:

END

---

4.7

   It is possible to define constraints to be taken into account during

   path computation procedures (e.g., IRO/XRO).

Should expand IRO and XRO.

Should also concern a reference.

---

5.1.1

s/AN1) moreover,/AN1). Moreover,/

s/both), as/both), are included as/

s/Figure 3 below./Figure 3./

s/Figure 4 below./Figure 4./

---

5.1.1 Figures 3 and 4

Are both abstract nodes called AN1? It's confusing.

---

I think we can fix Figure 5 to avoid the confusing link numbering as...

           .........................................

           :                                        :

           :         Physical Topology @ PNC1       :

           :                                        :

           :         +----+              +----+     :

           :         |    |S1-1          |    |S2-3 :

           :         | S1 |--------------| S2 |------ - -(S31)

           :         +----+          S2-1+----+     :

           :       S1-2/                    |S2-2   :

           :          /                     |       :

           :     S3-4/                      |       :

           :     +----+        +----+       |       :

           : S3-1|    |S3-3    |    |       |       :

   (R1)- - ------| S3 |--------| S4 |       |       :

           :     +----+    S4-1+----+       |       :

           :    S3-2\             \S4-2     |       :

           :         \             \        |       :

           :          \S5-1         \       |       :

           :           +----+        \      |       :

           :           |    |         \     |       :

           :           | S5 |          \    |       :

           :           +----+           \   |       :

   (R2)- - -----   S5-2/    \S5-3        \  |       :

           :    \     /      \        S8-2\ |S8-1   :

           : S6-1\   /S6-5    \S7-1        \|       :

           :     +----+      +----+      +----+     :

           :     |    |S6-4  |    |S7-4  |    |S8-5 :

   (R3)- - ------| S6 |------| S7 |------| S8 |------ - -(S32)

           : S6-2+----+  S7-2+----+  S8-3+----+     :

           :      /            |           |        :

   (R3)- - -------         S7-3|           |S8-4    :

           : S6-3              |           |        :

           :...................|...........|........:

                               |           |

                             (S11)      (S12)

---

5.1.1

s/it under PNC/it is the PNC's/

---

5.2

s/to setup/to set up/

---

5.2.1.1

s/To setup/To set up/

s/to setup/to set up/

s/5.2.1, MDSC/5.2.1, the MDSC/

---

5.2.2

   Appendix Error! Reference source not found. provides the detailed

I spy Microsoft Word!

---

5.2.3

s/MDSC understands/the MDSC understands/

---

5.2.3.1

s/When this IP link/When an IP link/ ??

---

5.2.4

s/MDSC understands/the MDSC understands/

s/To setup/To set up/ (three times)

---

OLD

5.3.1. Linear Protection (end-to-end)

NEW

5.3.1. Linear Protection (End-to-End)

END

---

5.3.1

s/MDSC performs/The MDSC performs/

s/both the paths for working/the paths for both the working/

s/MDSC would/the MDSC would/

s/MDSC requests/The MDSC requests/

s/with1+1/with 1+1/

---

5.3.2

s/Network domain 2 and 3/network domains 2 and 3/

---

5.4

s/On the perspective of MPI/From the perspective of the MPI/

s/receiving notification/receiving a notification/

---

6.

s/at remote node/at remote nodes/

---

Nice to see one of the authors thanking himself in the acknowledgments:)

Sent: 11 March 2021 17:37

CCAMP,

 

Thanks

Daniele & Fatai

---

From: <[email-masked]>
Date: Fri, 26 Mar 2021 09:59:28 -0000

Hi Adrian, 

Thanks for the support and review of the document; your detailed comments
and suggestions are very welcome. We will address them when we update the
I-D. 

BR, Dan. 

From: CCAMP <[email-masked]> On Behalf Of Adrian Farrel
Sent: 25 March 2021 22:56
To: 'Daniele Ceccarelli' <daniele.ceccarelli=[email-masked]>;
'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] WG last call on
draft-ietf-ccamp-transport-nbi-app-statement-12

Hi,

Best,

Adrian

== Minor ==

---

2.

---

2.

choice on this point.

---

---

5.4

---

== Nits ==

General point:

- noun "a setup"

- verb "to set up"

---

---

Abstract

OLD

NEW

END

---

1.

---

1.

---

1.

OLD

   multi-domain scenarios.

NEW

   scenarios.

END

---

1.1

---

1.1

---

2.

---

2.

---

3.2

OLD

NEW

END

s/by an "-"/by a "-"/

---

---

4.1

---

4.1

   controllers)

---

---

4.2

s/PNcs/PNCs/

---

4.3

---

4.3.1

---

4.3.1

s/CMI,the/CMI, the/

s/to setup/to set up/

---

---

OLD

NEW

END

---

4.5.2

---

4.6

OLD

NEW

   supported:

END

---

4.7

---

5.1.1

---

5.1.1 Figures 3 and 4

---

           :                                        :

           :                                        :

           :         +----+              +----+     :

           :         |    |S1-1          |    |S2-3 :

           :         +----+          S2-1+----+     :

           :       S1-2/                    |S2-2   :

           :          /                     |       :

           :     S3-4/                      |       :

           :     +----+        +----+       |       :

           : S3-1|    |S3-3    |    |       |       :

           :     +----+    S4-1+----+       |       :

           :    S3-2\             \S4-2     |       :

           :         \             \        |       :

           :          \S5-1         \       |       :

           :           +----+        \      |       :

           :           |    |         \     |       :

           :           | S5 |          \    |       :

           :           +----+           \   |       :

           :    \     /      \        S8-2\ |S8-1   :

           : S6-1\   /S6-5    \S7-1        \|       :

           :     +----+      +----+      +----+     :

           :      /            |           |        :

           : S6-3              |           |        :

                               |           |

                             (S11)      (S12)

---

5.1.1

---

5.2

s/to setup/to set up/

---

5.2.1.1

s/To setup/To set up/

s/to setup/to set up/

---

5.2.2

I spy Microsoft Word!

---

5.2.3

---

5.2.3.1

---

5.2.4

---

OLD

NEW

END

---

5.3.1

s/with1+1/with 1+1/

---

5.3.2

---

5.4

---

6.

---

From: CCAMP <[email-masked] <mailto:[email-masked]> > On
Behalf Of Daniele Ceccarelli
Sent: 11 March 2021 17:37
To: CCAMP <[email-masked] <mailto:[email-masked]> >
Subject: [CCAMP] WG last call on
draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

 

Thanks

Daniele & Fatai

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 26 Mar 2021 10:24:16 +0000

Indeed i forgot to add Thursday March 25th COmB (close of MY business) 😃

Jokes aside, thanks for the thorough review and thanks for the pointer to RFC5737, I couldn’t really understand what was wrong with the ID nits when saying “non compliant IPv4 addresses.

Authors, for your convenience I’m copying here below the address blocks to use:

   The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
   and 203.0.113.0/24 (TEST-NET-3) are provided for use in
   documentation.

Thanks
Daniele

From: Daniel King <[email-masked]> On Behalf Of [email-masked]
Sent: den 26 mars 2021 10:59
To: [email-masked]; Daniele Ceccarelli <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: RE: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Hi Adrian,

Thanks for the support and review of the document; your detailed comments and suggestions are very welcome. We will address them when we update the I-D.

BR, Dan.

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: 25 March 2021 22:56
To: 'Daniele Ceccarelli' <daniele.ceccarelli=[email-masked]<mailto:daniele.ceccarelli=[email-masked]>>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Hi,

I see Daniele got excited and requested publication, but it seems that it is still 25/3 where I live. Sorry my review is right at the deadline, but it’s a long document.

It's nice to see guidance on using IETF technology. Particularly useful when the ingredients include a list of YANG models. So I support publication of this document.

I did find it a hard read and confess to not having checked the JSON examples (55 pages were quite enough for me!).  Along the way I collected a few minor issues and whole host of nits.

Best,
Adrian

== Minor ==

---

2.

---

2.

---

---

5.4

---

== Nits ==

General point:
- noun "a setup"
- verb "to set up"

---

---

Abstract

OLD

---

1.

---

1.

---

1.

OLD

---

1.1

---

1.1

---

2.

---

2.

---

3.2

OLD

s/by an "-"/by a "-"/

---

---

4.1

---

4.1

---

---

4.2

s/PNcs/PNCs/

---

4.3

---

4.3.1

---

4.3.1

s/CMI,the/CMI, the/
s/to setup/to set up/

---

---

OLD

---

4.5.2

---

4.6

OLD

---

4.7

---

5.1.1

---

5.1.1 Figures 3 and 4

---

                               |           |
                             (S11)      (S12)

---

5.1.1

---

5.2

s/to setup/to set up/

---

5.2.1.1

s/To setup/To set up/
s/to setup/to set up/

---

5.2.2

I spy Microsoft Word!

---

5.2.3

---

5.2.3.1

---

5.2.4

---

OLD

---

5.3.1

---

5.3.2

---

5.4

---

6.

---

CCAMP,

Thanks

Daniele & Fatai