Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Tony Przygienda <> Thu, 15 February 2018 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4807712DA41; Thu, 15 Feb 2018 08:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 oiUduNeAV7d0; Thu, 15 Feb 2018 08:53:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 436DB12AF84; Thu, 15 Feb 2018 08:53:52 -0800 (PST)
Received: by with SMTP id x4so1980219wmc.0; Thu, 15 Feb 2018 08:53:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xnoUMF3MqtiRJ19pHNO5Cft8HObS+sXo1T1/xa1sFsI=; b=JGY5i4HS/HD6tiMb/cMpmdTfZ3LRG4VTbkSjaAKVAfz5OoRE19ChXKEHwujbt6cztQ w/x3GhXxtrJa2MtbPyKXp3/oEkeMPsIxM/IXYH/3NUT3kGwSL1vDV3qxg+4gW+nLjnpV 2+DGQdpxSAseybF/0sp3j4ljx/Z+hB7POk9pQ2CRMlV3s2PkXWSqldzCTYnEwR+i1Erb m4hwfutJh6UN6ZGzVl4tFd8IpUfbJOBacVXn6d/JLMoUQ7icXXxMwGpjXoPS6N1zOxlm dPMgZReyYYlXJH/b+okiQtdaEwbMCBKXNIkdFBYlQ/SZ8EW9sTqJNIsLiLBqItqRsRYp f0QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xnoUMF3MqtiRJ19pHNO5Cft8HObS+sXo1T1/xa1sFsI=; b=B6ri4fFwliin/sg1LryEaZVEF7bJQBDbl+0lyIs7DbWirgghWIABZYGzStv+q7GHaN rLULm/2ajsAYtdsv4IjOP2Wi+Yimn9CoaalEdfJFsKK9zycJjDFM00Jl4T572ERyDL57 6hNCyBMc3wLQE5wyvzQ2zQ2FXWAV+S8Tg351i9Nn4ezZf9gx6mBe9aDKYtP7jr9kmm42 jChKqK4gkJcHiD3/RwfIc6vhRiuQLSOEGBGDd/rjd1IKr96BkAnd3l505q9CEDMNbLt8 f9FYyCj1PNZKU+mU9I4VR06n6sCawSyobruwcqt9+wQ7u1OUrs313hZU93jOpIVPZTZv 3p6g==
X-Gm-Message-State: APf1xPD0sT8wZrYnvg8H4T6u7ZYIr7SMSiJzR8j+G2aSWrBhKtb+Iyw2 J/Kb1VLzPZihaLQaZhw8rlW3SYWr1EJNOduf8s8=
X-Google-Smtp-Source: AH8x227MxLuWSXnD8nZwnfWiX1ZULICd7pAOF/DKmHy0BqurFWnNczD51XknSzlFLyFXFimR9nQVUsPrMigk/wIpD9o=
X-Received: by with SMTP id g2mr4071707edi.4.1518713630818; Thu, 15 Feb 2018 08:53:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Feb 2018 08:53:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Tony Przygienda <>
Date: Thu, 15 Feb 2018 08:53:10 -0800
Message-ID: <>
To: Greg Shepherd <>
Cc: Eric C Rosen <>, Xiejingrong <>, Jeff Tantsura <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="f40304394f787b05eb0565431215"
Archived-At: <>
Subject: Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Feb 2018 16:53:56 -0000

On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <> wrote:

> For the record, there is no SR Registry. There is only an IGP Algo Type
> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
> section 8.5

So is that a good idea, having multiple drafts in flight with fields
expecting to have magic couplings to each other while leaving e'thing
"unspecified" to "publish RFCs" while we "decide things later"?

> a)       No IGP or SR working group has any charter to mandate any of the
>> BIER technology so as well-meant the suggestion seems to be, it has no
>> standing in IETF working procedures as far as I can see unless according
>> charters are extended by ADs. Unless I'm missing something here.
> If a WG points to a registry of any kind, a draft is all that is needed to
> justify an new entry in the registry.

Forthcoming today as I said ... For all practical purposes having a _single
value_ in a field that can accommodate more in the future can mandate a
registry and we already have 0 BTW. And it looks we will/may have more so I
can't follow the apparent logic here that we don't need a registry because
"we don't have values today" but so we publish an RFC without registry
which implies we don't need a registry later in case we have values?

>> b)       More as a question: Can we even publish an RFC now
>> (experimental) pointing to an SR draft as normative? And if, how do we move
>> it to intended standards track unless SR draft is a standards RFC?
> Nobody is asking to reference it now. The current issue on the table to to
> leave it undefined with only default value, so let's stick with the current
> issue.

I leave it to the judgement of IESG and AD then whether they progress
things to RFCs (intended for standards track) with undefined fields for
which the "interpretations" will come later. The issue was here 6 months
ago and was muscled, the issue is obviously now on an open consensus
building list. It will not magically go away. I still see a registry as a
long-time proven way to anchor multiple ideas coming into a technology
safely and fail to understand how we have things that will be "aligned" but
are not "depending to each other" while "documentations" are not
"registries" from the continuation of your email, Greg ...  And I lived
through enough codepoint squatting wars and WG charters stepping onto each
others feet to not having the desire to have one more on my hands, hence I
welcome the thread ...

--- tony