IETF Logo Mail Archive

Re: [babel] RtgDir review: draft-ietf-babel-information-model-11.txt

"STARK, BARBARA H" <bs7652@att.com> Mon, 02 November 2020 20:05 UTC

Return-Path: <bs7652@att.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5397F3A1216; Mon, 2 Nov 2020 12:05:28 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 CYEJTOoFZ0kQ; Mon, 2 Nov 2020 12:05:27 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0144B3A11E0; Mon, 2 Nov 2020 12:04:29 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A2JtHFp014423; Mon, 2 Nov 2020 15:04:25 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 34hmvrkvvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2020 15:04:25 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K4Mi8017221; Mon, 2 Nov 2020 15:04:23 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K4I3L017080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2020 15:04:19 -0500
Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id DE8D44005C1F; Mon, 2 Nov 2020 20:04:18 +0000 (GMT)
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (unknown [135.50.89.109]) by zlp30484.vci.att.com (Service) with ESMTPS id B9CBD4005C1C; Mon, 2 Nov 2020 20:04:18 +0000 (GMT)
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 2 Nov 2020 15:04:12 -0500
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Mon, 2 Nov 2020 15:04:12 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Geoff Huston' <gih@apnic.net>, "'rtg-ads@ietf.org'" <rtg-ads@ietf.org>
CC: "'rtg-dir@ietf.org'" <rtg-dir@ietf.org>, "'babel@ietf.org'" <babel@ietf.org>, "'draft-ietf-babel-information-model.all@ietf.org'" <draft-ietf-babel-information-model.all@ietf.org>, "'last-call@ietf.org'" <last-call@ietf.org>
Thread-Topic: [babel] RtgDir review: draft-ietf-babel-information-model-11.txt
Thread-Index: AQHWpsrbOgEYG24sekSUx14m/vPz3Km1VaFQ
Date: Mon, 02 Nov 2020 20:04:12 +0000
Message-ID: <04540478027d442c9bb448ebd132b9b8@att.com>
References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net>
In-Reply-To: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.127.123]
x-tm-snts-smtp: D5DA6D70E167529B99144850B9B067066EEA7EF6E86610968AF17AB2BDF738832
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-02_13:2020-11-02, 2020-11-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 clxscore=1011 malwarescore=0 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011020152
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/AZVrs8m6IbItSM7_aZNPA8gzRHY>
Subject: Re: [babel] RtgDir review: draft-ietf-babel-information-model-11.txt
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 20:05:28 -0000

Thanks, Geoff, for reviewing. I'm sorry for my delayed response, but am glad that others were able to respond. Given their responses, I'm resolving your comments as follows. Please let me know if you disagree. And though I'm proposing no change, I really do appreciate your review. String length and units are extremely important concepts when specifying an information or data model.

> Nits:
> 
> It seems anomalous to this reviewer that it goes to the bit lengths of some
> integer valued objects, yet leaves string objects undefined in terms of any
> maximum length.

No change. As noted by others in their responses to this comment, the bit lengths of integer values must be specified because they correspond to protocol parameters that have specific length requirements. String objects have no length specified by the protocol. In this case, it is common practice (for information and data models) to leave length specification to the implementation. I've learned this the hard way over the last 15 years (specifying string lengths that turned out too short or too long for how someone wanted to use them).

> "centiseconds"? Really? "tenths of seconds" would be clearer to most
> readers!

No change. As noted by others in their responses to this comment, centiseconds is the unit specified by the protocol (so the info model is using consistent unit nomenclature) and it is the preferred manner for expressing this unit in data models I'm involved with.

Thanks again,
Barbara

v2.23.0 | Report a Bug | By Email