Subject: Re: [Teas] Status update on draft-ietf-teas-sf-aware-topo-model 07

From: tom petch <[email-masked]>
Date: Fri, 19 Mar 2021 10:28:23 +0000

From: Xufeng Liu <[email-masked]>
Sent: 24 February 2021 15:51

Hi Tom,

Thanks for your further check on this. We have posted the updated version ( https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-07) to fix the issues that you raised, along with some other updates.

<tp>

Looks good.  I had forgotten about numeric references being invalid.

One last comment pro tem.  I think it debatable as to whether RFC765 should be Informative or Normative.  I realise that the RFC is Informational which is not very helpful of the authors and the RFC has not been approved as a Downref but that is one for the AD or some such to resolve.

Tom Petch
Best regards,
- Xufeng

On Tue, Nov 24, 2020 at 5:59 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Sent: 20 November 2020 01:26

Hi Tom,

We have posted an updated version https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-06, to address the two additional items below.

<tp>

Indeed and here are some more:-(

Both YANG module still import te-topology as an I-D not RFC

[Xufeng]: Updated.

Your e-mail address in the YANG modules does not match that in the I-D

[Xufeng]: Fixed.

ETSI references would benefit from a URL both in YANG and in I-D references

[Xufeng]: Added the URL in I-D references. I’m a little hesitant to add it to YANG since other references in the “reference statement” do not do it, and this reference has a very long URL that would be used multiple times.

ETSI GS NFV has been updated three times since December 2014

[Xufeng]: Updated.

Why the underscore in _3GPP.28.801?

[Xufeng]: A reference anchor tag in IETF cannot start with a numerical number so 3GPP.28.801 would not work. The underscore is a trick that we took from the draft-defoy.

Why the underscore in Figure 2 etc in the ASCII version of the I-D?

[Xufeng]: Fixed them with the notes.

draft-defoy expired three years ago; that is problematic for a Normative Reference

[Xufeng]: I think that it should be informative, and moved it as such.

Tom Petch

Thanks,
- Xufeng

On Thu, Apr 9, 2020 at 7:08 AM <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
From: Xufeng Liu <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Sent: 12 March 2020 21:57

We have posted the updated version ( https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-05 ) to fix the issues that you raised.
Thanks a lot,

<tp>
Xufeng,

looks better and apologies for being slow to respond.

C.12 IANA, C.13 Security look odd and contradict s.5, s.6.  Is there any reason for them to exist?

Security s.6 does not conform to the boiler plate referenced in RFC8407.  This asks that sensitive nodes be called out and I would think that at least the enable nodes for connectivity matrix and link terminations would qualify for that.

[Xufeng]: Fixed. C.13 is now following RFC8407. s.5, s.6. were mistakenly merged from a different draft (https://tools.ietf.org/html/draft-ietf-teas-use-cases-sf-aware-topo-model-00). These two sections have now been removed.

Tom Petch

- Xufeng

On Tue, Mar 26, 2019 at 6:05 AM tom petch <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
Xufeng

Some quirks.

Introduction/Abstract do not mention support or lack thereof  for NMDA
(which the IESG have been calling for).
[Xufeng]: Added.

Introduction does not have a reference for YANG leaving the question of
version number uncertain
[Xufeng]: Added.

Terminology fails to reference RFC8174
[Xufeng]: Fixed

Expand on first use, perhaps in Terminology, is helpful - TOSCA, SF2LTP,
SF2SF, SF2TTP,
[Xufeng]: Fixed

CSO
[Xufeng]: Authors and contributors discussed CSO and decided to remove it from this document and put it into a separate document.

yang-version 1 is rather limiting
[Xufeng]: Use 1.1 now.

YANG import statements lack references (which YANG 1.1 allows)

/       reference "TBD";/
       reference "RFC XXXX - SF Aware TE Topology YANG Model"; /
[Xufeng]: Fixed these statements.

   module ietf-cso-dc
no version
no copyright
no reference to the I-D
no description clauses
no reference clauses
somewhat short of ready IMHO- I think that this needs a lot of work!
[Xufeng]: As mentioned above, CSO is removed from this document and planned to be put into a separate document.

IANA Considerations
   RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
   actual RFC number (and remove this note).
I suggest that this apply throughout the I-D and that the Note is placed
at the start, before the Introduction (the RFC Editor are happy with
just the one note)
[Xufeng]: Changed as suggeted.

RFC6020 is a better reference for the IANA Considerations
[Xufeng]: Right. Use  RFC6020 now.

   [I-D.ietf-netmod-revised-datastores]
RFC8342
[Xufeng]: Fixed.

   [I-D.ietf-netmod-yang-tree-diagrams]
RFC8340
[Xufeng]:  Fixed.

   [I-D.ietf-i2rs-yang-network-topo]
RFC8345
[Xufeng]: Fixed.

     import ietf-actn-vn {
does not appear in section 1.3
[Xufeng]: Added.

Tom Petch

----- Original Message -----
From: "Xufeng Liu" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>>
To: "TEAS WG" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>>
Sent: Saturday, March 23, 2019 12:02 PM
Subject: [Teas] Status update on draft-ietf-teas-sf-aware-topo-model

> Current Status:
>
>   *  The updated revision -03 was posted on Mar 11, 2019:
>
>      > Editorial fixes.
>
> Open Issues:
>
>   *   None.
>
> Next Steps:
>
>   *  Update the document to align with the latest versions of
>      referenced documents, including draft-ietf-teas-yang-te-topo,
>      RFC8340, RFC8342, RFC8345, and RFC8459.
>   *  Update the section of Security Considerations according to latest
>      guidelines.
>   *  Get further reviews.
>   *  YANG doctor's review.
>   *  Working Group Last Call after completing above.
>
> Thanks,
> - Xufeng
>

------------------------------------------------------------------------
--------

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

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 22 Mar 2021 22:15:26 -0400

Hi Tom,

Thanks.
As for whether RFC7665 should be Informative or Normative, we will bring it
to the AD's attention.

Best,
- Xufeng

On Fri, Mar 19, 2021 at 6:28 AM tom petch <[email-masked]> wrote:

> Thanks for your further check on this. We have posted the updated version
> ( https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-07) to
> fix the issues that you raised, along with some other updates.
>
> <tp>
>
> One last comment pro tem.  I think it debatable as to whether RFC765
> should be Informative or Normative.  I realise that the RFC is
> Informational which is not very helpful of the authors and the RFC has not
> been approved as a Downref but that is one for the AD or some such to
> resolve.
>

> We have posted an updated version
> https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-06, to
> address the two additional items below.
>
> <tp>
>
> [Xufeng]: Added the URL in I-D references. I’m a little hesitant to add it
> to YANG since other references in the “reference statement” do not do it,
> and this reference has a very long URL that would be used multiple times.
>
> [Xufeng]: A reference anchor tag in IETF cannot start with a numerical
> number so 3GPP.28.801 would not work. The underscore is a trick that we
> took from the draft-defoy.
>
> On Thu, Apr 9, 2020 at 7:08 AM <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
> From: Xufeng Liu <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>>
> We have posted the updated version (
> https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-05 ) to
> fix the issues that you raised.
> Thanks a lot,
>
> <tp>
> Xufeng,
>
> Security s.6 does not conform to the boiler plate referenced in RFC8407.
> This asks that sensitive nodes be called out and I would think that at
> least the enable nodes for connectivity matrix and link terminations would
> qualify for that.
>
> [Xufeng]: Fixed. C.13 is now following RFC8407. s.5, s.6. were mistakenly
> merged from a different draft (
> https://tools.ietf.org/html/draft-ietf-teas-use-cases-sf-aware-topo-model-00).
> These two sections have now been removed.
>
> Tom Petch
>
> - Xufeng
>
> On Tue, Mar 26, 2019 at 6:05 AM tom petch <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]
> >><mailto:[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>> wrote:
> Xufeng
>
> Some quirks.
>
> [Xufeng]: Authors and contributors discussed CSO and decided to remove it
> from this document and put it into a separate document.
>
> [Xufeng]: As mentioned above, CSO is removed from this document and
> planned to be put into a separate document.
>
> IANA Considerations
> From: "Xufeng Liu" <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>><mailto:[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>>>
> To: "TEAS WG" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]
> <mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>>
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>