Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Ben, 

On 8/26/19, 11:11 AM, "Lsr on behalf of Benjamin Kaduk" <[e-mail] on behalf of [e-mail]> 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" <[e-mail]> 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" <[e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr