Hi Ben,
On 8/26/19, 11:11 AM, "Lsr on behalf of Benjamin Kaduk" <lsr-boun...@ietf.org
on behalf of ka...@mit.edu> wrote:
Hi Acee,
On Mon, Aug 26, 2019 at 03:02:18PM +0000, Acee Lindem (acee) wrote:
> Hi Ben,
>
> On 8/22/19, 9:44 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote:
>
> On Fri, Aug 23, 2019 at 12:30:27AM +0000, Acee Lindem (acee) wrote:
> > Hi Ben,
> >
> > On 8/22/19, 1:46 AM, "Benjamin Kaduk via Datatracker"
<nore...@ietf.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-ospf-yang-26: Discuss
> >
> > When responding, please keep the subject line intact and reply
to all
> > email addresses included in the To and CC lines. (Feel free to
cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found
here:
> > https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
> >
> >
> >
> >
----------------------------------------------------------------------
> > DISCUSS:
> >
----------------------------------------------------------------------
> >
> > (1) Can we check whether it's okay to use the yang "string"
type for raw
> > cryptographic keys (e.g., ospfv2-key, ospfv3-key)? My
understanding was
> > that yang strings were limited to human-readable, but that the
crypto
> > keys could be raw binary values.
> >
> > It does only include human-readable keys. Here is the RFC 7950 YANG
ABNF definition.
> >
> >
> > ;; any Unicode or ISO/IEC 10646 character, including tab,
carriage
> > ;; return, and line feed but excluding the other C0 control
> > ;; characters, the surrogate blocks, and the noncharacters
> > yang-char = %x09 / %x0A / %x0D / %x20-D7FF /
> > ; exclude surrogate blocks
%xD800-DFFF
> > %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF
> > %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF
> > %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF
> > %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF
> > %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF
> > %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF
> > %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF
> > %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF
> > %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF
> > %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF
> > %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF
> > %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF
> > %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF
> > %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF
> > %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF
> > %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF
> > %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF
> > %x100000-10FFFD ; exclude noncharacters
%x10FFFE-10FFFF
> >
> > However, this is the intent as this is support for implementations
that don't support key-chains (RFC 8177). The "Security Considerations"
recommend key chains. We'll add the hexadecimal specification as another reason
for preferring key-chains.
>
> Okay, that's enough to resolve the discuss.
>
> >
> >
> > (2) Do we need to say anything about how to indicate when there
are
> > discontinuities for the various "counter" types?
> >
> > I've never heard any mention of counter discontinuities in the
context of OSPF control plane counters.
>
> Oh, I think this is more of a YANG thing than an OSPF thing (and I'm
hardly
> a YANG expert). That is, the yang:counter32 and similar types are
> constrained to only ever increment ("count events that happened",
roughly),
> as opposed to a gauge32 that measures the current level of something
and
> can go up or down, or a generic uint32. Of course, in the real world
> software crashes or restarts, so a YANG consumer might in practice
see the
> value of a "counter" type go backwards, even though that's forbidden
by the
> spec. In some cases (and I don't know exactly when it becomes most
> relevant), the YANG model includes a "discontinuity time" (e.g.,
router
> restart time) to indicate when the counters were last reset to zero,
in
> order to give consumers a sense for how long it took the counter to
get
> that big. It's entirely possible that this doesn't make sense for
the OSPF
> counters, and if you tell me that I'm happy to clear.
>
> Searching for "RFC YANG discontinuity" brings up several
representative
> results, such as RFC 8343, which says:
>
> leaf discontinuity-time {
> type yang:date-and-time;
> mandatory true;
> description
> "The time on the most recent occasion at which any one
or
> more of this interface's counters suffered a
> discontinuity. If no such discontinuities have
occurred
> since the last re-initialization of the local
management
> subsystem, then this node contains the time the local
> management subsystem re-initialized itself.";
>
> I did some research and the OSPF MIB (RFC 4750) did have a discontinuity
time (ospfDiscontinuityTime). I added discontinuity-time for each applicable
object in the -28 version.
Thank you for doing the research -- I had forgotten to even check for an
analogous MIB!
The updates in the -28 look good, and I've cleared in the datatracker.
Thanks much for the review - especially the detailed review of the YANG model.
Acee
-Ben
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
