Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

Martin Bjorklund <mbj@tail-f.com> Wed, 17 October 2018 06:48 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCC712F1A5 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 23:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjcS6FW68yT7 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 23:48:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0E128D68 for <netmod@ietf.org>; Tue, 16 Oct 2018 23:47:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 662AF1AE0399; Wed, 17 Oct 2018 08:47:55 +0200 (CEST)
Date: Wed, 17 Oct 2018 08:47:54 +0200 (CEST)
Message-Id: <20181017.084754.967504021504890362.mbj@tail-f.com>
To: chopps@chopps.org
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <sa6zhvd7d32.fsf@chopps.org>
References: <sa64ldl8ypz.fsf@chopps.org> <CABCOCHQNrdNhAqEx_KMToJw6kRHCWAP2e10cBTH8r_b-MZYSnQ@mail.gmail.com> <sa6zhvd7d32.fsf@chopps.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/c3btUcwBeYtFSpIzS51EsQbVk0I>
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 06:48:02 -0000

Hi,

Christian Hopps <chopps@chopps.org> wrote:
> 
> Andy Bierman <andy@yumaworks.com> writes:
> >
> > This draft needs to define the module-tag encoding wrt/
> >    - valid characters (e.g., some subset of UTF-8)
> >    - min/max length (e.g., implementation MUST support at least 64 chars
> > and can support larger)
> 
> I'm looking for suggestions on how to do this subset. We had intended
> to allow for as wide as possible content; however, I think disallowing
> tabs, newlines, carriage returns is more than reasonable. Has a type
> like this already been standardized or is there an example available
> somewhere?
> 
> > Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
> > structure to specify the naming authority.
> >
> > According to the YANG module, the data type is a plain string, which
> > includes lots of
> > problematic chars and zero-length strings.
> >
> > Does the string "routing" match "ietf:routing" or "vendor:routing"?
> > How
> > about "routing:bgp"?
> 
> No. Do we need to state that non-matching strings don't match?

The word "match" is imo problematic.  Use "equal" if that's what you
mean.  But you're not actually using the word "match" in the draft, so
that's fine.  However, I think the draft can be clarified.  See below.

In this case, it _seems_ like there's some hierarchy with tags
like:

  ietf:routing
  ietf:routing:rib

For example, does ietf:routing:rib imply ietf:routing?

>From your last emails, it seems that the idea is that tags are really
just strings with the only property that they can be compared for
equality.  If this is the case, I think it can be made more clear in
the document.  And if this is the case, I think that type "string" is
actually fine.  If someone wants to assign the tag
"vendor:acme::::::::: ", let them.

OTOH, if the idea is that the tags are hierarchical, and
ietf:routing-rib implies ietf:routing, then a more specific type is
needed, and more text.


/martin



> 
> > Is the char ":" allowed in a tag?
> 
> Yes, why not?
> 
> > Is "vendor::::::::" a valid tag?
> 
> Again why not?
> 
> The only thing the draft talks about are standard prefixes. Why should
> a standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but
> not Y) than just sticking to what it *is* standardizing.
> 
> Perhaps a bit of text saying more explicitly that only the prefix is
> restricted would help though?
> 
> > IMO this draft does not need to define any specific module-tag content
> > but
> > it does need to define
> > in precise terms how a protocol encodes a module-tag and how a
> > module-tag
> > match is determined.
> 
> We considered leaving out all the predefined tags, but conversely we
> also thought it would be useful to establish a base set. We went with
> the latter obviously. Perhaps it just needs to be trimmed down more?
> 
> Thanks,
> Chris.
> 
> >
> >
> > Thanks,
> >> Chris.
> >>
> >
> > Andy
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>