Further thoughts on -16 (as my previous comments included below are).
What is the status of Appendix B? I find this a thorny question.
Appendices are usually regarded as not Normative, with a statement
called for when it is otherwise. This is a YANG module which non-NMDA
servers will implement so that says it is Normative, to me. On the
other hand, the world is going NMDA - I do not know how fast - so this
is more like Historic; or non-Normative?
I do not know the answer but do know we can expect to see this several
times, so I am thinking that some thought and guidance from an Ops AD
would be valuable.
IANA Considerations should have a
reference: RFC XXXX
for each module registered
Additionally, my comments about the YANG module in the body of the
document apply to Appendix B and C namely
- [RFC ... looks wrong in a YANG module
- import without reference
Does the YANG module in Appendix C need a Copyright statement?
Should the YANG module in Appendix C be registered? It took a while for
the IETF to see the need to define formally such things as
example.com
so I am thinking it probably should be lest we get many different
varieties in the wild.
And I would like a Note to the RFC Editor asking them to update the
dates with the date of publication especially since there are five such
dates rather than the usual two.
Tom Petch
----- Original Message -----
From: "tom p." <daedulus@xxxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Cc: <teas-chairs@xxxxxxxx>; <teas@xxxxxxxx>;
<draft-ietf-teas-yang-te-topo@xxxxxxxx>; <db3546@xxxxxxx>
Sent: Tuesday, June 05, 2018 6:01 PM
> Lou et al
>
> I note that the YANG module in this I-D has Reference statements to 20
> other RFC, which is good, but only one of the twenty appear in the
> References for the I-D, which I think is not good, and needs to be
> fixed.
>
> Also, some of the RFC which appear in Reference clauses of the YANG
> module appear in [square brackets] e.g. [RFC6001] which I think should
> not be there.
>
> In the same vein, there are imports of four other YANG modules but no
> indication as to which RFC they can be found in - again, I think that
> that needs fixing with a Reference statement.
>
> A quick pass suggests the missing references are to
> 1195 missing
> 3209 missing
> 3272 missing
> 3471 missing
> 3630 missing
> 3785 missing
> 4201 4202 4203 4206 all missing
> 4872 missing
> 5152 missing
> 5212 missing
> 5305 missing
> 6001 missing
> 6241 ok Norm
> 7471 missing
> 7752 missing
> 7579 missing
>
> Russ's comment about Section 1.1 does not seem to have been addressed.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "The IESG" <iesg-secretary@xxxxxxxx>
> To: "IETF-Announce" <ietf-announce@xxxxxxxx>
> Cc: <draft-ietf-teas-yang-te-topo@xxxxxxxx>; <teas-chairs@xxxxxxxx>;
> <teas@xxxxxxxx>; <db3546@xxxxxxx>
> Sent: Wednesday, May 16, 2018 3:40 PM
>
> > The IESG has received a request from the Traffic Engineering
> Architecture and
> > Signaling WG (teas) to consider the following document: - 'YANG Data
> Model
> > for Traffic Engineering (TE) Topologies'
> > <draft-ietf-teas-yang-te-topo-15.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > comments on this action. Please send substantive comments to the
> > ietf@xxxxxxxx mailing lists by 2018-05-30. Exceptionally, comments
may
> be
> > sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > This document defines a YANG data model for representing,
> retrieving
> > and manipulating Traffic Engineering (TE) Topologies. The model
> > serves as a base model that other technology specific TE Topology
> > models can augment.
> >
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
> >
> > IESG discussion can be tracked via
> >
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > The document contains these normative downward references.
> > See RFC 3967 for additional information:
> > rfc5212: Requirements for GMPLS-Based Multi-Region and
Multi-Layer
> Networks (MRN/MLN) (Informational - IETF stream)
