I have been looking some more at this I-D and have some more doubts and
queries.
s.2.2
OLD
The area and area/interface containers respectively define the OSPF
configuration and operational state for OSPF areas and interfaces.
NEW
The area and area/interface containers define the OSPF
configuration and operational state for OSPF areas and interfaces
respectively.
The current text suggests area corresponds to configuration and
area/interface to operational state!
OLD
"WG Web: <http://datatracker.ietf.org/group/lsr/>
NEW
"WG Web: <https://datatracker.ietf.org/group/lsr/>
I am puzzled by the use of derived-from...
container router {
when "derived-from-or-self(../../header/type, "
+ "'ospf:ospfv2-router-lsa')" {
why is this derived-from-or-self when I can see nothing derived from the
base type?
container network {
when "derived-from-or-self(../../header/type, "
+ "'ospfv2-network-lsa')" {
ditto
container summary {
when "derived-from(../../header/type, "
+ "'ospfv2-summary-lsa-type')" {
why is this not derived-from-or-self when there are derivations from the
base type?
when "derived-from(../../header/type, "
+ "'ospfv2-external-lsa-type')" {
description
"Only applies to AS-external LSAs and NSSA LSAs.";
Yes, since they are derived-from external-lsa but external-lsa per se
will be excluded which I assume is intended
identity operation-mode { description "OSPF operation mode.";
I cannot see any explanation of where this is used or what it is
router capabilities (RFC7770) appears in the YANG but is not itself a
feature; is there an assumption that all current routers will support
RFC7770?
lsa-id
sometimes dotted-quad, sometimes uint32, sometimes both; why?
grouping ospfv2-lsa {
....
container header {
must "(derived-from(type, "
....
description
"Opaque type and ID only apply to Opaque LSAs.";
The must and the description match but why are they part of container
header and not part of the leaves?
Tom Petch
----- Original Message -----
From: "tom petch" <ietfc@xxxxxxxxxxxxx>
Sent: Friday, July 05, 2019 5:30 PM
I think that this could do with a few tweaks.
RFC 7884 is in the YANG module but not in the I-D references nor in the
body of the I-D.
The names of the TLV are not quite the same as in IANA and since new TLV
are not regarded as updates to RFC7770, then precision is called for in
order to find them with confidence via IANA
I cannot find router-address-tlv in IANA nor is there a YANG reference
clause and since there was some confusion over router-id in 2018, this
is one I want to check against its RFC, whatever that is.
The RPC can disrupt routing; elsewhere I have seen such actions limited
by a default
nacm:deny all
so users have to be positively configured to invoke the RPC.
I am unclear about rpc clear-neighbor. Yes, it clears the adjacency but
what then? Is it held down, allowed to come back up or what?
rpc or action? I have yet to work out the pros and cons of each but was
rather expecting action as opposed to rpc for these.
leaf cost {type uint16
mostly have a range, but some do not; should they?
typedef ospf-metric { type uint32 { range "0 .. 16777215";
but
leaf cost { type ospf-metric { range "0..16777214";
looks odd; if intended, I suggest adding a note of explanation
some leaf metric are type ospf-metric others are type uint16; again
looks odd (but may be intended)
references to bfd-yang are not consistent
RFC YYYY - YANG Data Model for Bidirectional
Forwarding Detection (BFD).
draft-ietf-bfd-yang-xx.txt:
YANG Data Model for Bidirectional Forwarding Detection (BFD)";
I think the former clearer
I notice that many of the YANG enumeration have numeric values, others
do not, which makes me curious; not wrong but since YANG does not put
them on the wire, I think that having no numeric value is commoner
With priority
e.g. list unreserved-bandwidth {
leaf priority {
which is high and which is low?
Likewise with boolean e.g.
leaf best { type boolean; description
"Indicates if the alternate is the preferred.";
does true mean the alternate is preferred?
This I-D is big - 125pp - and I will not finish reviewing it by July
17th but expect to do so some time later in the month - I will post
again when I have.
Tom Petch
----- Original Message -----
From: "The IESG" <iesg-secretary@xxxxxxxx>
To: "IETF-Announce" <ietf-announce@xxxxxxxx>
Cc: <lsr@xxxxxxxx>; "Stephane Litkowski"
<stephane.litkowski@xxxxxxxxxx>; <draft-ietf-ospf-yang@xxxxxxxx>;
<lsr-chairs@xxxxxxxx>; <aretana.ietf@xxxxxxxxx>
Sent: Tuesday, July 02, 2019 5:55 PM
Subject: [Lsr] Last Call: <draft-ietf-ospf-yang-23.txt> (YANG Data Model
for OSPF Protocol) to Proposed Standard
>
> The IESG has received a request from the Link State Routing WG (lsr)
to
> consider the following document: - 'YANG Data Model for OSPF Protocol'
> <draft-ietf-ospf-yang-23.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 2019-07-17. 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 that can be used to
configure
> and manage OSPF. The model is based on YANG 1.1 as defined in RFC
> 7950 and conforms to the Network Management Datastore Architecture
> (NDMA) as described in RFC 8342.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/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:
> rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic
Engineering (Experimental - Independent Submission Editor stream)
> rfc1765: OSPF Database Overflow (Experimental - IETF stream)
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/lsr
>
