Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Tue, 17 October 2017 16:49 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1732E13207A for <ietf@ietfa.amsl.com>; Tue, 17 Oct 2017 09:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level:
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 pU9MPpracldq for <ietf@ietfa.amsl.com>; Tue, 17 Oct 2017 09:49:45 -0700 (PDT)
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127A7126E64 for <ietf@ietf.org>; Tue, 17 Oct 2017 09:49:45 -0700 (PDT)
Received: by mail-pf0-f175.google.com with SMTP id e64so1750635pfk.9 for <ietf@ietf.org>; Tue, 17 Oct 2017 09:49:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pfzpvujrBjddN3ZqhNn/RJoZB15fFXAUNKMt8UwyiMw=; b=azNgs4vhYCTRPgaImLl/fHZ+hTg413ocxBdteua5dwCQuqMkqktiBs2NwRRiKRUQ6J VQdmJ28JUkhYxQbOKQNwzumXP6Y+QKva894yqJJtRhXo129qfTbKvzAwWDLq+PmFAhfL QQoAVf4qxEqRcIE1xj5tnIozwN8e5QNOy++63aRgql7I9CUtE9rY08voqkbcwXL4jgg2 Yv1Q0usd+4yK+ZP2o/GL1lR4G7z4hdLOM8EhcGOAXuN3Qui3NqhCqyRL+WvobBlUVAAC x0qZrrea124rsIL3C5DkCoF5GyaCanNVc6gpOknx4xiPscntrENa3IRqMY6m5L1tSD8y RJEQ==
X-Gm-Message-State: AMCzsaUAkL6HFOluvSHriYf4TASdjmGW9EnkdeHM05UBTcD8ABBYRhbK lGWAB7VLT4out4fCoM8o436YTXoKi0Y=
X-Google-Smtp-Source: AOwi7QDjYd+DN7eW6fL15ysLeM+07Kkss6u1IIriY6ARdFSNbtLRqSjvpzx99xpkPFLBrXrvOsFNQw==
X-Received: by 10.98.211.203 with SMTP id z72mr12595524pfk.328.1508258984246; Tue, 17 Oct 2017 09:49:44 -0700 (PDT)
Received: from [192.168.1.103] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id h67sm21194790pfk.60.2017.10.17.09.49.43 for <ietf@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 09:49:43 -0700 (PDT)
Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard
To: ietf@ietf.org
References: <150531137507.30405.6179845967838123305.idtracker@ietfa.amsl.com> <3d65a756-fe9b-19de-fd94-40f4618d729b@cisco.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <c6efd2ae-5f5d-1699-89fe-0d2f28b71cdb@alumni.stanford.edu>
Date: Tue, 17 Oct 2017 09:49:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <3d65a756-fe9b-19de-fd94-40f4618d729b@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/QCa6bwoNofEE9_3kOb8g0RKnZpc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2017 16:49:46 -0000

Hi -

On 10/13/2017 11:55 PM, Benoit Claise wrote:
...
> Since RFC8049 is not implementable and therefore not implemented,

That's rather a leap of faith.  The fact that spec is badly broken
and probably should not have been published in the first place isn't
of itself going to stop someone from using it as the basis for an
implementation of *something*.  RFC 1065 is a great example of something
quite unimplementable as specified (its usage of ASN.1 MACRO
notation is gobbledygook) yet nonetheless saw rather wide deployment.
If there is a need for something, folks are pretty good at DWIM.

It may well be true that there are no implementations of this module,
but the rationale given is most unconvincing, particularly given the
importance of module name/content stability in stitching this stuff 
together.

> keeping the same YANG module name seems about right.

This group seems to be rather attached to module names, and
in ways at odds with the on-the-wire significance of those names.
Seems like some thought needs to be given to configuration management.

Randy