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" <[email protected]> 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" > <[email protected]> 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. -Ben _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
