Re: [netmod] moving forward with schema mount

Lou Berger <lberger@labn.net> Wed, 24 January 2018 15:40 UTC

Return-Path: <lberger@labn.net>
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 59E9912DA44 for <netmod@ietfa.amsl.com>; Wed, 24 Jan 2018 07:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 A7OF4uDJYtxn for <netmod@ietfa.amsl.com>; Wed, 24 Jan 2018 07:40:46 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16081126C3D for <netmod@ietf.org>; Wed, 24 Jan 2018 07:40:46 -0800 (PST)
Received: from [::1] (port=41698 helo=fs2.dc.labn.net) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from <lberger@labn.net>) id 1eeNAJ-00019Q-L6; Wed, 24 Jan 2018 18:40:43 +0300
To: joel jaeggli <joelja@bogus.com>, Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
References: <BF9C1543-4471-4CB3-9A26-451F45A2E4B6@juniper.net> <878tcnz9pc.fsf@nic.cz> <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
From: Lou Berger <lberger@labn.net>
Reply-To: lberger@labn.net
Message-ID: <5ebf6026-fb59-8bd2-8f72-3b5be9667de7@labn.net>
Date: Wed, 24 Jan 2018 10:40:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <3d69eabd-5fed-1655-b7fa-b76809580ef4@bogus.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BR1a-hy3Palylm4IFiMrzVSh_sU>
Subject: Re: [netmod] moving forward with schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 24 Jan 2018 15:40:48 -0000

One additional point below.

n 01/24/2018 09:35 AM, joel jaeggli wrote:
> 
> 
> On 1/24/18 8:07 AM, Ladislav Lhotka wrote:
>> Hi,
>>
>> Kent Watsen <kwatsen@juniper.net> writes:
>>
>>> Thank you all for the important discussion since the completion of WGLC on Nov 6th.
>>>
>>> Per normal process, drafts typically progress once LC comments are
>>> address unless significant faults are found.  Post LC comments have
>>> been made, which needed consideration, notably the relationship with
>>> NMDA and rfc7895bis and an alternate representation of inline schema.
>>> These have been considered respecting their impact on the last call
>>> consensus and it is the position of the chairs that it is best to
>>> advance the existing schema-mount document at this time.
>> I guess I have no chance but strongly object to this. Is it normal to
>> proceed this way without reaching WG consensus and against the will of
>> *both* document authors?
> Once the document is adopted by the working group it's the working
> group's document.
> 

A document moving away from the original authors intent or even
agreement has happened before in the IETF.  I'm aware of several cases
of it *right now*, one in this group the others in different areas.  In
the case of this group, the original (lead) author choose to remove
themselves from the work and others in the WG took over the pen.  In the
other WGs, the original authors dropped the work and new authors took it
over.  In the case of the work that I initiated that this happened with,
I'm not sure if I'm listed or not as it's been so long since I looked at
the draft, but I know I'm no longer on the front page and the WG chair
appointed editor is a non-original author who I recommended.  So your
current position is not unique, nor counter to our process.

As a reminder, it is the responsibility of the document editors to
document WG consensus -- they have a lot of latitude in how they do
this, but in the end, WG consensus is what should be captured once an a
topic is discussed. It is also the WG chairs responsibility to ensure
that a document reflects WG consensus, this includes ensuring that the
document editors/authors follow consensus and appointing editors when
the authors need assistance in this.  An editor can be appointed if you
and Martin think this is necessary, but I think the preference of the
chairs is that we don't at this late date.

Lou


> The consensus call was made back here:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html
> 
> To my mind the discussion that we picked up in the new year highlights
> the limitations of the existing draft without it being fatally flawed.
> To wit (and this is my opinion), this one is stable and should proceed,
> clearing the path for drafts with normative dependencies; we should
> proceed with an update in a timely fashion.
> 
> IETF Last call serves a useful function in that is exposes the problem
> discussed here beyond the working group, particularly to those who
> depend on schema mount today. I think we understand in making this
> judgement call where the working group participants stand today.
> 
>>> Given that there are significant concerns for how the solution
>>> proposed in this draft operates with NMDA, we do think it reasonable
>>> to add an applicability statement to the draft that covers its
>>> operation in NMDA implementations. We do not believe that such a
>>> statement substantively alters the draft nor would it impact drafts
>>> that normatively reference the current draft.
>>>
>>> In addition to resolving the remaining open thread [1],
>> Hmm, who resolved this thread? Lou proposed some text and nobody
>> expressed any agreement with it. In fact, I believe it is nothing more
>> than hand-waving.
>>
>> I must say that the work on this draft was very frustrating for me. Even
>> more than on RFC 8022, and this tells you something.
>>
>> Lada
>>
>>> we also agree
>>> with the recently made comment that the schema mount draft should
>>> allow the use of rfc7895bis (i.e., not reference /modules-state),
>>> thereby enabling the draft's use (though not ideal) on servers
>>> supporting rfc7895bis.
>>>
>>> The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement. 
>>>
>>> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>>>
>>> Thanks,
>>> Kent, Lou, and Joel
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>