[netmod] namespace encoding in draft-ietf-netmod-yang-json-02

Andy Bierman <andy@yumaworks.com> Wed, 10 December 2014 18:14 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439A91A1A0C for <netmod@ietfa.amsl.com>; Wed, 10 Dec 2014 10:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 B6ygdCQMhG_9 for <netmod@ietfa.amsl.com>; Wed, 10 Dec 2014 10:14:09 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011B11A6FF9 for <netmod@ietf.org>; Wed, 10 Dec 2014 10:14:07 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id gd6so2945685lab.15 for <netmod@ietf.org>; Wed, 10 Dec 2014 10:14:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SFVlsuxyaYDpdf9HJlb8AqiSsXwM4AodhW8Ev1fdZ4w=; b=EaIffLXz+5D5vXZdotoonwrd8t9Joc4vWwVLXQQ7PNoAme7cxlOBf3q2Lb3td9MqMt 7CkTFbMM9OTuGlM58aOsKcKCWmwZliMFGREsubx2RIUWSph1AgIkViTse3K604Vc5q33 LSnDDSvfSZmmBJePYwmyTUC5zPER3YE3Rnptt9qrEJLaUOCI7jPDABLrd138zfJ99/yN 6iEtUufiWGXEu0KXelra8bTqhFwsMpzIfcOQP0r1/LeGAR0eW7gFRTPplpFMmeiAOiqq tmYLrk3EmeKg28D+jlLWwW+2esWkry2iohzNc4VGJsg3OJmmKUTOEYOl607ftdsjWhJh kSHw==
X-Gm-Message-State: ALoCoQnFL42VyXPQYi4M02QIjK8yjADl1xX5OvMAO8HLm+AKOq916K0FhIn0wXSJJPdp5yDmlqmp
MIME-Version: 1.0
X-Received: by 10.152.206.108 with SMTP id ln12mr319357lac.3.1418235246371; Wed, 10 Dec 2014 10:14:06 -0800 (PST)
Received: by 10.112.157.233 with HTTP; Wed, 10 Dec 2014 10:14:06 -0800 (PST)
Date: Wed, 10 Dec 2014 10:14:06 -0800
Message-ID: <CABCOCHQQ5YSnuj6UzuhrU0eaqxCW2e7autY980PasRdrp7XVww@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dyGWwlrLJTC9X7BbB96OcdW6_bg
Subject: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 10 Dec 2014 18:14:11 -0000

Hi,

Sec 4 has changed the rules for module names:

   Names with namespace identifiers in the form shown in Figure 1 MUST
   be used for all top-level YANG data nodes, and also for all nodes
   whose parent node belongs to a different namespace.  Otherwise, names
   with namespace identifiers MUST NOT be used.


So it is a protocol error if a prefix is used twice in a row:

   /A:foo/A:bar     --> causes a protocol error and MUST be rejected
   /A:foo/bar MUST be used instead

IMO this is very fragile and does not follow the Postel Principle.
In this example the server knows module 'A' and it is the correct
module for node 'bar'.  Yet it MUST reject the input according
to the new rules.

I prefer these rules:

   - The namespace for a node MUST be uses in top-level
     nodes and if the namespace is changing.
   - If no prefix is present, then the namespace associated with
     the parent node is used

IMO it is too much work for the server to verify that
a prefix is not used. Parsing a prefix is not a burden,
since the code to parse the prefix must be already there.

It is also more hassle on clients that are constructing URLs
from multiple functions. They have to know which prefix
MUST NOT be used.



Andy