Hi Tom,
On 7/5/19, 12:30 PM, "tom petch" <ietfc@xxxxxxxxxxxxx> wrote:
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.
See inline.
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.
This is defined in RFC 3630 for OSPFv2 Traffic Engineering LSAs. I've added separate opaque containers for the different opaque LSA types.
I hope this makes things a lot clearer.
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 don't see this for RFC 8349 RPCs. Can you cite some examples?
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?
No - it is not held down - just cleared as the corresponding CLI command has done for 25 years.
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.
I think RPC is appropriate in this case as this is what we've implemented in other models.
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)
I've made all these consistent and added the ospf-link-metric type for the cases of the 16-bit link metric.
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
Fixed.
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
It depends on whether numeric values were previously provided in the OSPF MIBs.
With priority
e.g. list unreserved-bandwidth {
leaf priority {
which is high and which is low?
I believe priority 0 is the highest. RFC 3630 doesn't state this explicitly.
Likewise with boolean e.g.
leaf best { type boolean; description
"Indicates if the alternate is the preferred.";
does true mean the alternate is preferred?
Yes - clarified the description.
Thanks,
Acee
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
>
