Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

Christian Hopps <chopps@chopps.org> Sat, 28 March 2020 13:39 UTC

Return-Path: <chopps@chopps.org>
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 6D9A33A03F1 for <netmod@ietfa.amsl.com>; Sat, 28 Mar 2020 06:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 UrPaDPXD1Rnn for <netmod@ietfa.amsl.com>; Sat, 28 Mar 2020 06:39:36 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 43C6E3A0365 for <netmod@ietf.org>; Sat, 28 Mar 2020 06:39:36 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A14076085F; Sat, 28 Mar 2020 13:39:35 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <DB7PR07MB5657BAF5920781FCD32BB5E3A0CD0@DB7PR07MB5657.eurprd07.prod.outlook.com>
Date: Sat, 28 Mar 2020 09:39:34 -0400
Cc: Christian Hopps <chopps@chopps.org>, Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7198F1E3-AF32-4195-AED0-97C6DFD1A7C7@chopps.org>
References: <01000170c16b721e-b5be8d27-8f4a-4355-9682-424f0dc5f337-000000@email.amazonses.com> <01000171182b030c-b715fdd4-0d1a-4373-a2b4-ba26e19b3232-000000@email.amazonses.com> <DB7PR07MB5657B7FF2AC7FFB4AE81333FA0CC0@DB7PR07MB5657.eurprd07.prod.outlook.com> <4FC34FCE-02B7-4959-AFFD-4DE84F4389B4@chopps.org> <DB7PR07MB5657BAF5920781FCD32BB5E3A0CD0@DB7PR07MB5657.eurprd07.prod.outlook.com>
To: tom petch <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-C9IiVks0GrkUK465bElLEeRwZk>
Subject: Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04
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: Sat, 28 Mar 2020 13:39:38 -0000


> On Mar 28, 2020, at 8:36 AM, tom petch <ietfc@btconnect.com> wrote:
> 
>> A wholesale lack of YANG reference clauses; perhaps half a dozen needed
> I can see 2 places I might could put these, in the "astronomical-body" leaf that references the IAU and in the "geodetic-system" for the default value. We are creating an IANA registry for the values in geodetic-system though so perhaps you are asking for an IANA reference instead? I don't see 4 more obvious places for external references, could you help point them out?
> <tp> A good starting point is any reference in the body of the I-D should be in the YANG module too in a reference clause, such as www.iau.org, IS6709, WGS84 and may be more than once for different description clauses.  velocity could include the formula or refer back to RFCXXXX perhaps timestamp too.  RFC8344 has enough (but not too many IMHO).

I'll go through the doc, and see what else I might could add. A couple points in the meantime though...

Some of these references (non-normative) in the document are for the comparisons to other work, and they point at other outside normative definitions for similar objects. I think it would be wrong to put references in the YANG module that point away from the definitive work (this document) and towards some other normative standard.

For velocity, referring back to the RFC that defines the module within sub-statements of the module seems rather redundant. The reference at the top of the module is the default reference for the module, if one starts adding the same reference to module sub-statements where does it end?

Other than that, I'll comb through again to look for normative references that aren't yet in the module, and also address your other concerns in a follow up version of the document.

Thanks for the review and comments!

Chris.