Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

John Scudder <jgs@juniper.net> Mon, 24 May 2021 21:04 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0319F3A08F9; Mon, 24 May 2021 14:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=g/4tRche; dkim=pass (1024-bit key) header.d=juniper.net header.b=jzohf2g6
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 gFkzEcuxJkj3; Mon, 24 May 2021 14:04:39 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 EB82F3A08F8; Mon, 24 May 2021 14:04:38 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14OKwkoj019629; Mon, 24 May 2021 14:04:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=wSKdToivn+skaEeCzp1rsf0hk9E1zoDdOskzQhXhLzw=; b=g/4tRcheQvg9LkCVYS4Ogtue2ToTSmDXPkJGYN6DaCjaQ3aYonMwDULJ8WJm3qRPZLdb sQih/+U7TI8zCprDyMpOlRAn8lS7k8BSEaGMufSUtpK/NqHgZPNyb4zQWkrt5gFJzzLB tkpFkKau5qyFouKpIxgkio2r5qXtwfJDMGlSmTQV/qcbbYFZ/tKPiocRyNBZVB4EOPB5 bEs1IcagBJc72XIoRvymtNVMVPL16JSBENaFmdOjkLUgXezeoKaLBsSUYbQI3Z+Tvwd3 LethXEC60PJcbiIvS2ZIu2dVh3cciB7pNx5Ja7vjxlhi6J1UNmec403fGqFfMtkOgv46 wg==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2171.outbound.protection.outlook.com [104.47.58.171]) by mx0a-00273201.pphosted.com with ESMTP id 38r936hm32-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 May 2021 14:04:35 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C8tk5a0BUFpArGRIAyNujYlhD9T5orfiDFBLbbw3n/YJFgqtlegzFiv1yG2hErPEs7abGpz867rmdTzibcVjPqbozU4UhKKkwBUsefdg5C/3NlPBHDGUEKW8PPl9wa8gA7dw7DtU4T0UsoDWhHe0/F1eQgmXE2ZLktPJ8ymOZmloaSG5XkiOpGlRB6h2h7+5juuRVOQVMCX78itnXvbR8Dzc/SmTOLztdhsY4r+z9TuvbdD7mtSixEXw3a4hW+hK6ryp27FCwhYCEFH1sZxn/8Zj+WiaBZhdnMWHCAR9c8p4rDsPiyW5UHZjqngJ2gjBSY8e6uKO+W75jJZWNuEPsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSKdToivn+skaEeCzp1rsf0hk9E1zoDdOskzQhXhLzw=; b=fvOAmfUfqx1Hs2KNC+7S8A0sloxYLQt/5ZiRPRGjD0PMVj/ZsKpsUrHYaalAPSg0PrhQJGI+osQTo5p+7GrCovHryHe09bJLwwK5Ynxd0AmiV+KNNdLqKzwp027SYkMrKUKmT0tNvjNx+KZLsg7uZQicD0soBtVlAdSvMU7Fad1R//ZkrxEn+FylZieP3uLs/2n+aAP2cfcvkfZAX+GAAduufOdtKwotxnKpP/xAcQ4+SIn4vLlHZ9cfUijzNCaaVahtHyMT0G2IihMiluLvN3jslIHQptrIlDcaH6Y807zsGuVZOOpXBlPzU7We20ShlrQ+nKIWzNnl0YPAm1ASNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSKdToivn+skaEeCzp1rsf0hk9E1zoDdOskzQhXhLzw=; b=jzohf2g62Vlz0gwVBF+XfduKGO7LV3/9fSRkCFs2NoP3k/Z2uZivze83zYaMa9J6mHdmXreETjOWaD1BbMtbwCJCKPG4m0hG9/LMKo1Q5+mLbBNujMP0sGS2F2MmO3gQyUe9i2yaSPxt2lsv3nOodPaIFNvWZI5pRYwDx+yE3XM=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6623.namprd05.prod.outlook.com (2603:10b6:208:e3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.15; Mon, 24 May 2021 21:04:31 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4173.018; Mon, 24 May 2021 21:04:31 +0000
From: John Scudder <jgs@juniper.net>
To: Charlie Perkins <charles.perkins@earthlink.net>
CC: Routing Over Low power and Lossy networks <roll@ietf.org>, John Scudder via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "mariainesrobles@googlemail.com" <mariainesrobles@googlemail.com>, "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>
Thread-Topic: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
Thread-Index: AQHXNVsZVxHxg8VYVkSdat85+ymoxKrXXjIAgBv334A=
Date: Mon, 24 May 2021 21:04:31 +0000
Message-ID: <A2BD41FA-1D12-4DCD-BF6E-BFB580DB4588@juniper.net>
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> <f80a127b-55a7-9ef6-d7b1-5b6358b1a61d@earthlink.net>
In-Reply-To: <f80a127b-55a7-9ef6-d7b1-5b6358b1a61d@earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.6)
authentication-results: earthlink.net; dkim=none (message not signed) header.d=none;earthlink.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80520d8e-b528-4904-1218-08d91ef786c7
x-ms-traffictypediagnostic: MN2PR05MB6623:
x-microsoft-antispam-prvs: <MN2PR05MB6623504343284ABB5FE0EAD0AA269@MN2PR05MB6623.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +1xmfVUd937tIzs3GTV5NxG9LsbAY2nBauVF11SPGoS5I2XvUczgz2XmMvlTXNo6G4LO+UdFlXmbbXv1W2MrqLfPt4XTcCAs8/fIxo6+NTL6yYQMaXLZypGd7ypvHZDA4yzLP0OAFB06L3sXRTLhkqNR0lY1njSBFxG6sj232/ojpz+3DUlivjo3XXAkorTjzofSheea+E3+BXSGcMAV9SRnHreC9u2AAVNUg9fFCXNCmXAummpVYj3RcBWWY8ctvY76SH93tC0Jd55m0Sfv05r/jDTDIZm/MW+GwOGYLIwIjCDiu8tCpmPg9gRLZaCerEOQYrmMnknFK8+8GHQQqN30tiM7fwVC5TupuzOvDRppsf0FRf/d/7CSjef7Ro9oTm1Y7Rm9tEMnTls1tfI1PeqxMyP3kCYMKJW3HtZpodRgpHMM4zTaYfvLE/pwX34Z0/LhW09eFWOWNJTP6v985DCvWxKu4DHYHxOV2a39CFEyB7o44iIIEK+Sw6ptiT6lVrgevaje4moBswlXe0pVzn0qQNGAT0Cmkl2X8xKbtbkMNScyPHRDbC4qznbk15IOSGIzd6FNZL55LHDeL2HOBKQ1qsXFI+vlpJmdzBwElUk0Aqv9dYNkl8O5xOxADsDSeBAqLsNCSdeBRFbN+xR4O+q3bzO0ILty7l3TWQG3NZwCsvD421wBQz/k7aPVUnp93wIeaJuTsg8uxqnkMmRXyEtl62QxMzWCQ8nRHrvY2e0wsF4b1eh2csJsLO4m5Yu3gEe+xMmJHtkOJA3u9i6f2w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(376002)(396003)(39860400002)(5660300002)(6916009)(76116006)(91956017)(71200400001)(66574015)(6506007)(38100700002)(8676002)(6512007)(122000001)(26005)(64756008)(66556008)(316002)(66446008)(66476007)(2906002)(36756003)(66946007)(53546011)(54906003)(8936002)(966005)(478600001)(2616005)(83380400001)(86362001)(186003)(30864003)(4326008)(33656002)(6486002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?UnR6Vmg3bXZJL3RFWTEyaWdCRURaeHc1QUVaRHhqQ3FZeVVsc09vck1rcmRS?= =?utf-8?B?MVduYnhoWjJtN2doejNVWWdtclJRV2tsMkYxNDlOVWk2a2lQUWFnTldPVWl5?= =?utf-8?B?SHlVcEc1SjgrV25NK0RmRjFxNVVEc1prK0Y3QWtNZWNzTEh4ZjMySk1BV1FW?= =?utf-8?B?VVFIZjRObFNIdllWUmlJaHZlZlB4V0ZUN2xRN0JaVmc5dlNpa2FyNDMyMEFi?= =?utf-8?B?cDZPNWdvb2Vuelh4KzlXcTAyaVptalc0QlJ0d25xTVE0NFFCMXBOd2RMRUEw?= =?utf-8?B?bUFJTXk3WWtoTDVJdE1iVms1MCsvRlZrOXZDNkFsdlhFL0RHNlBGNVlhZm9X?= =?utf-8?B?cUppZ2MzQnkyV1I4QldVeU5hZkM5SVZaL3R3S2tJK3BaQXNwQU9YekRZaXhB?= =?utf-8?B?eTJoRmdMOFJ2V1R5OTBJai9zOFQrYlBaVUhLZWFsdGJVYjViL2w5NnM2Wmo4?= =?utf-8?B?d2QvV2dxNWU5TmFBa0xpcEUrWUxPTkVTS3MvK0RQaVFFU3V4SUN3dWh0U0Jt?= =?utf-8?B?cTBRL3N3dGUyd0t4Q3J4cXpOUHFJUmphK3BSSmMwWFZ1ZlNudURxTWg2V3V4?= =?utf-8?B?U1hmb0J6cFJ3Ull5bnRPVDZNbUx1STlxaGdsam94QXZRT2ExcDhwSW1kcndt?= =?utf-8?B?Q3Jsa0hnTUdPMXlFbTlSK1JWVWFXdW5hVTJkdWlGTklwNzhXbUw0S3Z1Sngx?= =?utf-8?B?cjdJZ0k1VWhUSUk2U080aEpVbzVpQ0F4WXJlaEo3RmFCN0VlNDFBaVZqTG56?= =?utf-8?B?dVozakJ5cnczQkNNTVIzVFJKVXRMVUFWQkJWVGNFZzZIbzY2Qk5KSDluc0pX?= =?utf-8?B?MUFUZkpjdkIvSFo1dllseGI0aVkyRSsvakhLbnFyc2N2WEZCWE5EWjdkWFhC?= =?utf-8?B?Yk9UMHhoeXp0RGlLZFdieXJsWnFiS2VnN0ZMSjlNcDJUbWhUWDFyQzAxSTVv?= =?utf-8?B?OVRROXRWUFVJUlJCazNnY25NZWZoMzFhYmRPOWRlMGpqUmpKNUpyUlNTQnV6?= =?utf-8?B?N3c3MGJpKzlKUVYvS1lBZmJzYkgwZjZCVzcrYU9UU1VDVnViSTBnOWxHeUo2?= =?utf-8?B?MFIrUGoweHQ4SkpRMHAraFc0VEYrS2VuRzgzLzY2SHIzMmVEZE4xcVp1dXBa?= =?utf-8?B?d1hUM0E3azE4cUJqeFRYNHEvYVE2Qm82S1crdFQ3S1NEdUJGcXRhUVNjVm40?= =?utf-8?B?d0IwNEVZZ0JVd2NDR2NWMGVmeWE0MS9YM3NQcU1xVFJPUUphWlpOY2p5c216?= =?utf-8?B?Q3QxdjRueGY4SkZld3czVWR5d2ZDZDBxdjFLZVlEVUNlYWVrMXhrQVpoQlRV?= =?utf-8?B?Tk12NGx6c3FlcmVOMTZ5QzcyVDRhbXZieXBBSWJ5MHlWdFUxZmFVMmxkYXdT?= =?utf-8?B?b25Kc2xQT2FKTFM4NXdYZ1ZNTGNjK1NjR3ZRRXV3ZkJRSDY4dTFjT21uSlly?= =?utf-8?B?NW9IY1d5c0ZaL2NtYzF4NU9wcWZibWJvS3czdldYOVphYXZTT2pUbXU0UXpC?= =?utf-8?B?VjhJVjF0VmtuUENsTXFnTk51ZDlOY1BRUmdJV2VBd1ZEbGJsVmo4NjMvKzJL?= =?utf-8?B?RFJhRmlQbS9vZVo4cmRyZkM3TFEwMEJQOG9VSHdLZjN0QXFrK2VJUnUzcW94?= =?utf-8?B?TmN2cWxCeHZ2cVZuY3pLY215dDBHRE1oWUJiQnBhUzJGelVua2NUaXdaTXBY?= =?utf-8?B?RTQ1VUZOMkQyNlFkcUwvNXRHbEJkYUVxZklFZ2tpVTFMbXh4OVNydnpQTXk5?= =?utf-8?B?Q05rZGZhalhXU2pxK0x4RVpILzRJTURMazNKaEVPNmwzNEtTUEZ5OWI2YWJY?= =?utf-8?B?OWNFNkowVDdnakxvQ3NzUT09?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <CFFB692DA6FDDC46AEACF062C6279829@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 80520d8e-b528-4904-1218-08d91ef786c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 21:04:31.4995 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: knldgQKemz/c8wQePr8i/nWLPaITvqzMQvVSE/hIBni4XbhIX4c11faeWufkVWlH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6623
X-Proofpoint-GUID: 9QPs2cTFUEh6d48ihs7xSseDg_V1La38
X-Proofpoint-ORIG-GUID: 9QPs2cTFUEh6d48ihs7xSseDg_V1La38
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-24_09:2021-05-24, 2021-05-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 impostorscore=0 adultscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=776 mlxscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105240124
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/YnY3yN6yL64IjkRgtIME-FBZ9s0>
Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2021 21:04:44 -0000

Hi Charlie,

Thanks for your reply and I apologize in turn for my own delay. My comments below.  

> On May 6, 2021, at 9:58 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
> 
> 
> Hello John,
> 
> It's taken a while for me to get to this, please excuse the delay. I
> have some followup to your comments interspersed below.
> 
> On 4/19/2021 1:31 PM, John Scudder via Datatracker wrote:

[…]

>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> A lot of effort has clearly gone into this work, thank you. I do have one topic
>> I want to DISCUSS, as it seriously impacted the readability of the document
>> from my point of view. I don’t anticipate that it will be very difficult to
>> resolve this DISCUSS as it relates to clarity and not to anything fundamental.
>> 
>> My chief difficulty with the document is placing it in context. No hints are
>> given to the reader as to what the expected network environment is. I think it
>> would be almost sufficient to say, for example “the network environment is
>> assumed to be the same as described in RFC 6550, Section 1” for example, but
>> without that hint and without a strong background in ROLL, I found myself
>> struggling. Figures 4 and 5 in particular lead me to believe the expected
>> environment looks similar to a classic ISP network — a collection of nodes
>> connected by point-to-point links. If this isn’t correct (and I bet it’s not)
>> that may have led me into incorrect assumptions, which may be reflected in my
>> other comments below.
>> 
>> Further, it’s not stated anywhere whether AODV-RPL is intended to stand alone
>> as its own routing protocol, or to be viewed as an extension of RPL. In the
>> former case, it seems the document is lacking details that are present in RFC
>> 6550. I’m assuming the latter is the case, but a clear statement to that effect
>> seems indicated.
> How about this text:
>   Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is
>   an IPv6 distance vector routing protocol designed to support multiple
>   traffic flows through a root-based Destination-Oriented Directed
>   Acyclic Graph (DODAG).  Typically, a router does not have routing
>   information for most other routers.  Consequently, for traffic
>   between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)
>   data packets either have to traverse the root in non-storing mode, or
>   traverse a common ancestor in storing mode.  Such P2P traffic is
>   thereby likely to traverse longer routes and may suffer severe
>   congestion near the root (for more information see [RFC6997],
>   [RFC6998]). The network environment that is considered in this document
>   assumed to be the same as described in Section 1 of [RFC6550].

That works, I’ll clear the discuss when you push out your next version.

>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> 1. Section 1:
>> 
>>    Reply.  AODV-RPL currently omits some features compared to AODV -- in
>>    particular, flagging Route Errors, blacklisting unidirectional links,
>>    multihoming, and handling unnumbered interfaces.
>> 
>> Your use of language is entirely up to you, but I feel obliged to point out
>> that there’s been a lot of discussion in the IETF community recently about use
>> of language that raises sensitive points, and about the term “blacklisting” in
>> particular. I understand that this is the only place in the document the term
>> appears, and since it refers to AODV you can’t just use another term, but
>> placing it in quotation marks might make it clear that it’s referring verbatim
>> to the language of RFC 3561.
> 
> This is an evolving issue.  I am fine with using quotes but otherwise
> maintaining consistent terminology.  For instance,
> 
>    AODV-RPL currently omits some features compared to AODV -- in
>    particular, flagging Route Errors, "blacklisting" unidirectional links
>    [RFC3561], multihoming, and handling unnumbered interfaces.

That works for me.

> If there is an official list of terms to search for please let us know.

It’s not quite an “official list of terms to search for” but we do now have a statement on this, https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

FWIW during my review I didn’t notice anything else that seemed like it needed to be addressed.

>> 2. Section 1:
>> 
>>   support for storing and non-storing modes.  AODV adds basic messages
>>   RREQ and RREP as part of RPL DIO (DODAG Information Object) control
>> 
>> Did you mean “AODV-RPL adds”?
> Yes, will fix.
> 
>> 
>> 3. Section 2:
>> 
>>    Symmetric route
>>       The upstream and downstream routes traverse the same routers.
>> 
>> Same routers? Or same links? (Or both, if multi-access links are part of the
>> mix, as I imagine they may be?)
> 
>      The upstream and downstream routes traverse the same routers and over
>      the same links.

It’s probably worth saying this explicitly.

>> 4. Section 4.1:
>> 
>>    OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
>>    message.  A RREQ-DIO message MUST carry exactly one RREQ option,
>> 
>> Should that say “one of its IPv6 addresses"? Is it even necessary to restate
>> this? RFC 6550 §6.3.1 already has a clearer requirement:
>> 
>>    DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
>>          identifies a DODAG.  The DODAGID MUST be a routable IPv6
>>          address belonging to the DODAG root.
> 
> I'm not quite sure what is requested.  Should it be "OrigNode sets the
> DODAGID field", relying on the definition provided in RFC 6550? Should
> it be "OrigNode sets one of its routable IPv6 address in the DODAGID field"?
> Honestly, I thought the meaning was clear.  Unless there is an
> objection, I reckon we will use the latter wording.

The latter wording is fine. I pointed out that 6550 already says this because presumably you don’t need to re-specify what’s already been specified there. If it’s just there for narrative clarity, that’s fine of course.

>> 5. Section S4.1:
>> 
>>   TargNode can join the RREQ instance at a Rank whose integer portion
>>   is equal to the MaxRank.
>> 
>> Not less than or equal, right? Strict equality to MaxRank is required?
> The existing text isn't good.  Instead,
> 
>   TargNode can join the RREQ instance at a Rank whose integer portion
>   is less than the MaxRank.

OK.

>> 6. Section 4.2:
>> 
>>    TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
>>    message.  A RREP-DIO message MUST carry exactly one RREP option,
>> 
>> Same as #4.

Presumably to receive the same change.

>> 7. Section 4.2:
>> 
>>   Address Vector
>>      Only present when the H bit is set to 0.  For an asymmetric route,
>>      the Address Vector represents the IPv6 addresses of the route that
>>      the RREP-DIO has passed.
>> 
>> The first time I read through this, I didn’t understand it at all. On
>> re-reading, I think you’re using the word “route” in two different ways in the
>> same sentence, the first time to mean “route” in the sense of an object in the
>> protocol, the second time in the more casual sense of “a path through the
>> network”. If that’s right, I suggest rewriting the second instance, as in “…
>> represents the IPv6 addresses of the path through the network the RREP-DIO has
>> traversed.”
>> 
>> Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any
>> given node have various IPv6 addresses? So maybe just lose the definite
>> article, as in “… represents IPv6 addresses of the path…”?
> 
> Good point.  We will use your formulation.

So “… represents IPv6 addresses of the path through the network the RREP-DIO has traversed.” Check.

[…]

>> 
>> 13. Section 5:
>> 
>>   Appendix A describes an example method using the upstream Expected
>>   Number of Transmissions" (ETX) and downstream Received Signal
>>   Strength Indicator (RSSI) to estimate whether the link is symmetric
>>   in terms of link quality is given in using an averaging technique.
>> 
>> This sentence needs a rewrite to make it grammatical. It works up until "is
>> given in using an averaging technique”.
> How about:
>    Appendix A describes an example method using the upstream Expected
>    Number of Transmissions" (ETX) and downstream Received Signal
>    Strength Indicator (RSSI) to estimate whether the link is symmetric
>    in terms of link quality using an averaging technique.

That’s clear. Thanks.

>> 14. Section 6.2.1:
>> 
>>      If the S bit in the received RREQ-DIO is set to 1, the router MUST
>>      determine whether each direction of the link (by which the RREQ-
>>      DIO is received) satisfies the Objective Function.  In case that
>>      the downward (i.e. towards the TargNode) direction of the link
>>      does not satisfy the Objective Function, the link can't be used
>>      symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
>>      be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
>>      the router MUST determine into the upward direction (towards the
>>      OrigNode) of the link.
>> 
>> The last sentence doesn’t make sense.
> How about:
>               ...  If the S bit in the received RREQ-DIO is set to 0,
>     the router MUST determine the upward direction (towards the
>     OrigNode) of the link.

Although this is clear enough in context, I suggest spending just a few more words on it: “… if the S bit in the received RREQ-DIO is set to 0, the router MUST determine whether the upward direction (towards the OrigNode) of the link satisfies the Objective Function."

I don’t insist but this wouldn’t have tripped me up the way the other text did.

>> 15. Section 6.2.1:
>> 
>>      If the router is an intermediate router, then it transmits a RREQ-
>>      DIO via link-local multicast;
>> 
>> On what interface? Routers generally can have multiple interfaces. Again, this
>> is a place a clear description of the network environment might have helped.
> 
> The link-local multicast should go out over all local interfaces.

OK. I guess there will be text forthcoming for this.

>> 16. Section 6.2.2:
>> 
>>   If the OrigNode tries to reach multiple TargNodes in a single RREQ-
>>   Instance, one of the TargNodes can be an intermediate router to the
>>   others, therefore it MUST continue sending RREQ-DIO to reach other
>>   targets.  In this case, before rebroadcasting the RREQ-DIO
>> 
>> The use of the term “broadcast” here confuses me. Is this “broadcast” in the RF
>> sense? Again, this is a place a clear description of the network environment
>> might have helped.
> This needs to be reformulated to avoid suggesting anything about RF
> broadcast.  TBD.

OK. Possibly something like “… before re-sending the RREQ-DIO according to Section X.Y.Z” might work?

>> 17. Section 6.2.2:
>> 
>>   send out any RREQ-DIO.  For the purposes of determining the
>>   intersection with previous incoming RREQ-DIOs, the intermediate
>>   router maintains a record of the targets that have been requested
>>   associated with the RREQ-Instance.  Any RREQ-DIO message with
>>   different ART Options coming from a router with higher Rank is
>>   ignored.
>> 
>> It’s not clear to me if the last sentence goes with the previous and if so,
>> how. Does it even relate to multiple targets? Also, different from what? If it
>> has the same ART Options (same as what?) is it *not* ignored?
> How about:
>                  .....                     For the purposes of
> determining the
>  intersection with previous incoming RREQ-DIOs, the intermediate
>  router maintains a record of the targets that have been requested
>  associated with the RREQ-Instance. Any incoming RREQ-DIO message having
>  multiple ART Options coming from a router with higher Rank than the
> Rank of
>  the stored targets is ignored.

Clearer, thanks.

>> 18. Section 6.3.1:
>> 
>>   implementation-specific and out of scope.  If the implementation
>>   selects the symmetric route, and the L bit is not 0, the TargNode MAY
>>   delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await
>>   a symmetric route with a lower Rank.  The value of RREP_WAIT_TIME is
>>   set by default to 1/4 of the time duration determined by the L bit.
>> 
>> It’s not an L bit though, it’s an L field.
> Good point!
> 
>> 
>> 19. Section 6.3.2:
>> 
>>   multicast until the OrigNode is reached or MaxRank is exceeded.  The
>>   TargNode MAY delay transmitting the RREP-DIO for duration
>>   RREP_WAIT_TIME to await a route with a lower Rank.  The value of
>>   RREP_WAIT_TIME is set by default to 1/4 of the time duration
>>   determined by the L bit.
>> 
>> Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to
>> infinity, as the text implies?
> Thanks for pointing this out.  We need to be explicit about it.  I don't
> think the RREP_WAIT_TIME should ever be zero or infinity. But, if it
> were, the implementations would still be interoperable in a sense.  Do
> we really want to get into exactly what wait times make sense in this
> context?

Seems better than letting implementors take their best guess at it.

>> Please do a global search for “L bit”, as there are additional instances I
>> haven’t called out.
>> 
>> 20. Section 6.4:
>> 
>>   Step 4:
>> 
>>       If the receiver is the OrigNode, it can start transmitting the
>>       application data to TargNode along the path as provided in RREP-
>>       Instance, and processing for the RREP-DIO is complete.  Otherwise,
>>       in case of an asymmetric route, the intermediate router MUST
>>       include the address of the interface receiving the RREP-DIO into
>>       the address vector, and then transmit the RREP-DIO via link-local
>>       multicast.  In case of a symmetric route, the RREP-DIO message is
>> 
>> As with #15: on what interface(s)?
> It should go out to all the neighbors over multiple interfaces if necessary.

OK. Again, I assume there will be text forthcoming.

>> 21. Section 10:
>> 
>>   fake AODV-RPL route discoveries.  In this type of scenario, RPL's
>>   preinstalled mode of operation, where the key to use for a P2P-RPL
>>   route discovery is preinstalled, SHOULD be used.
>> 
>> What type of scenario is that?
> 
> "In this type of scenario" -> "When rogue routers might be present"

Probably make that substitution then. But isn’t this potentially true in anything other than a small lab? (And some of you probably think I’m being naïve for thinking none of my lab routers are rooted.)

[…]

Regards,

—John