Re: [OPSAWG] WG LC for draft-ietf-opsawg-sdi-02

Warren Kumari <> Tue, 11 February 2020 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A959120B04 for <>; Tue, 11 Feb 2020 12:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y0VNq1aoq2ge for <>; Tue, 11 Feb 2020 12:42:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78106120A58 for <>; Tue, 11 Feb 2020 12:42:07 -0800 (PST)
Received: by with SMTP id n8so5659935qvg.11 for <>; Tue, 11 Feb 2020 12:42:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z4RlSk89lCkzMHaBS/ooPN1v43N293/XNuI47LaXhtY=; b=U/lo3famhheA+qMHuBqodi9gkfCRTjLXyjwogtXi65iOpP9TNCYsdKNRptXuP//Uj5 atUCjdz76El8J2afe8tdqia8C+WK3xALdqOLef0fLzssZ1/xbxTLlDnn5EiZ2wNJRmRd gZz34a1SB4xGLZsNGCwX5/lgAKxNIclzD62uAASWrD/MgQ9NHdi6kMehDB6buTwU62sZ Pnq7EIFq64rwCM0Hqa/ovyBEi8oDtMGBOEMWqzEOSUlrnczXE5r5Juv0Gql1+aTkcQFO 2J3AG+qqOePO5YdNCNAEnYrRjO6HQWcVs7rAR/nB6O/h1UL4hDn0aGgazC5o3vRz6eA0 1Bvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z4RlSk89lCkzMHaBS/ooPN1v43N293/XNuI47LaXhtY=; b=W1Z9GApItQw25fBEbOKff/64uSdQaQPu6Lvlk3NxFRJ4MHGXkrMwJDIk3AHiFYfLh/ GK4PEkPR1/Fw7hOGViRuUIekFdnKc+s6Jd41+8XOVk4dwXUCjUvuQ/m9gtEt5fqnMmL2 alSPaTvPleQMEgNx8c48SAzXvO4+MK5QyGVyvDa14WxSZ4ftxv8oFMS9s7WjIVra30t2 W4+F4wdMiMkjxC22ygPuXcBeFIhPaJvZzx5f7MGMlwgu/jaUmajh460vbUFfnUGYBCmn MS+EXsWJs7tNrtzxKzfSqZ0tMpQ7EU52UHDhYNXvvy2OFqOrz2/dlOIC5YiNmQukCikQ oFHQ==
X-Gm-Message-State: APjAAAW5Znwv4bVV8hJYXpyeePukdu+8Lzm/Zg/9hPR9UBGL+HTDoTyP NQtvYSGlgeOfWU14z+cCXGD4WJZgbbSTdLbHTjV5vg==
X-Google-Smtp-Source: APXvYqzPtZOIe4jEEvvdM4qhTpk+rupQ+xE4QRPy8i5LSWyeTgD6yz3ovDxWDpbumcdsO2k8KGBOtzy2Bf6rK3VDHh0=
X-Received: by 2002:a05:6214:10cb:: with SMTP id r11mr16234208qvs.59.1581453726273; Tue, 11 Feb 2020 12:42:06 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Tue, 11 Feb 2020 15:41:30 -0500
Message-ID: <>
To: "Joe Clarke (jclarke)" <>
Cc: opsawg <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-sdi-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 20:42:10 -0000

On Tue, Feb 11, 2020 at 10:19 AM Joe Clarke (jclarke) <> wrote:
> As a contributor, I think this document is mostly ready (and as previously stated, I like and support the work).  That said, after another read I found a few spelling nits and some comments:
> In Section 2, you paint the picture of a scenario, but “break the fourth wall” to explain what is existing and what is new functionality as well as state that the document prescribes using the SN as the unique identifier.  In the spirit of a scenario with additional context, I think you should clarify that the DHCP boot of an out-of-the-box device is _typically_ existing functionality.  Some vendors’ devices may not do this.

Good point. I have just submitted a new version which I think
addresses this (and your other comments below) -- I broke section 2
("Overview / Example Scenario") into 2 sections, "Overview" and
"Example Scenario". This required moving some text around, but I think
addresses your concern (and improves the document).

> ===
> Section 3.1:
> s/intially/initially/

DONE. Thank you!

> s/contrained/constrained/

DONE. Thank you!

> s/certifcates/certificates/

DONE. Thank you, there were 2 instances of this.

> ===
> Section 3.2:
> s/identfiers/identifiers/

DONE. Thanks!

> s/certificat/certificate/


> s/certifcates/certificates/


> ===
> Section 4.2:
> s/certifcate/certificate/

DONE. Well, this is getting embarrassing....

> ===
> Section 4.3:
> s/certifcate/certificate/

DONE. My old tooling would automagically spellcheck - I've just added
a spellcheck to VS Code (my new ID tooling editor).

> s/it never need/it never needs/


> I think you need some definition of “garbage” when doing config “tasting”.  It may be required that you standardize a header to indicate that the config file is encrypted so the device doesn’t try to process what could potentially be _lots_ of true garbage.  You have a sentence here about the exact detection method being out of scope (which is true for what is a config), but saying anything else is decryptable may not please the security folks too much.

Yes -- unfortunately there doesn't seem to be any sort of standard way
to add a comment device configs - these all work on different devices:
# I'm a comment
! I'm also a comment
; Yet another comment format
: This is getting silly
' Ugh, who thought apostrophes was a sane comment character?!

How about some text along the lines of: "Unfortunately there is no
standard way to identify if a config file has been successfully
decrypted, as different vendors use different configuration languages,
with different forms of comments, etc.
It is recommended that each vendor documents a standard header or
magic which devices can use to determine if the configuration seems
largely correct.
As an example, Cisco IOS configuration files use the '!' character as
a comment, and so Cisco IOS files could be expected to start with
something like '! This is a Cisco IOS configuration file'. Juniper
Network's JunOS uses '#' as a comment character, and so Juniper could
adopt the convention of using '## JunOS device configuration file' (or
some other string, to be chosen and documented by the vendor)."

Note that I have *not* included this is the newly posted version yet,
as I think it needs some polishing...

> Joe
> > On Feb 4, 2020, at 12:41, Joe Clarke (jclarke) <> wrote:
> >
> > With the publication of -02 of this draft, it seems to have reached stability.  There has been interest in both usage an implementation of this draft expressed in the past, but discussion has been quiet lately.
> >
> > This email serves as a two-week start of a WG LC for this document.  Please [re-]read this draft and comment on its content as well as whether or not you feel it’s ready.  WG LC will conclude on February 18, 2020.
> >
> > Authors and contributors, please reply on-list as to whether or not you are aware of any intellectual property attributed to this work.  Reply that either you are not aware of any such IP, or reply with the details of known IP while also making sure you complete any IPR disclosures in data tracker.
> >
> > Joe and Tianran
> > _______________________________________________
> > OPSAWG mailing list
> >
> >
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.