Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 12 April 2019 14:59 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46631205FC; Fri, 12 Apr 2019 07:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dJUOLMqh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MePc4e5u
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 eNm6hjWWlI6R; Fri, 12 Apr 2019 07:59:31 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259781207D6; Fri, 12 Apr 2019 07:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37811; q=dns/txt; s=iport; t=1555081171; x=1556290771; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fGwZszzQEjGpR3P2+gv19Yb3KpVpE85S5QWIEv8gsao=; b=dJUOLMqhsvDvDESpPl2+K0t9YVtCb0SF7ZIuFBOKE2o/yICt3fcMUc6F KCvZ+4qC5P58Hq1znPFuQprGVTpmnZgru6tczKxUGWWlyCKebAvfW6a+Q gnOEa08uwFP0IHmtu/laP0R9DSuZ0oGZxIN2M6rMf/VlSgy+FUMX8Ep3s M=;
IronPort-PHdr: 9a23:wz+eaBFDy4KeVJqcy1UJ2Z1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeXlcio2FdpPfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAABnprBc/4oNJK1lGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBDi8pJwNoVCAECxUTCodLA4RSikMcgjuJOY1hgS6BJANQBA4BARgBCgqEQAKFdiM0CQ4BAwEBCgECAQJtHAyFSgEBAQQBARgmAQEsBAcBDwIBCBEDAQEBIQEGByEGCxQJCAIEAQ0FG4MIgR1MAxwBAgwDoWoCihSCIIJ5AQEFgTEBg04NC4INAwaBMgGEXoQegkoXgUA/gRGDEj6CGkcBAQOBOEYNCYUrikkSEoIKhF+HYIw3NgkCggWGB4QihCGDRxqCB4NRgkkFh06Ee4tfhiqBRolDgl0CBAIEBQIOAQEFgU84gVZwFRohgjgBM4IKDBeBAQECgkiFFIU/cgGBKIx4gTABgR8BAQ
X-IronPort-AV: E=Sophos;i="5.60,341,1549929600"; d="scan'208,217";a="257990291"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 14:59:30 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CExT7T014668 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 14:59:30 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 09:59:29 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 10:59:28 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 09:59:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6htG6nvN6WF94Wkt/rsWuzdcQpTfXsTiCihljMp6B4Q=; b=MePc4e5uhuaKZ9DVizwgDEk5VK7d9BsmrFU8swJtqai7ty8faQ6Eh3HJ2ECG639QUfcxOoJm5QCU8ILY+feC+tW8wONXy4ftK1SkpLJoy+pwV8oKmsWj898MTTwaUIhDGSBCGPJuXVW006JJMZNcHpVMnEv9pmKsTpTeZ7opA9Q=
Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB2919.namprd11.prod.outlook.com (20.177.226.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.18; Fri, 12 Apr 2019 14:59:26 +0000
Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::95c3:573a:8b16:fb20]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::95c3:573a:8b16:fb20%4]) with mapi id 15.20.1792.018; Fri, 12 Apr 2019 14:59:26 +0000
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Nabil Benamar <benamar73@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, Nabil Benamar <n.benamar@est.umi.ac.ma>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
Thread-Topic: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
Thread-Index: AQHU8UBS+vV0iBOvHkaKFDXdzLKXOw==
Date: Fri, 12 Apr 2019 14:59:26 +0000
Message-ID: <D8D5F510.2F2BC8%sgundave@cisco.com>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com>
In-Reply-To: <D8D5F0B7.2F2BB8%sgundave@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com;
x-originating-ip: [128.107.241.164]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7ee9e1bb-e0ad-456c-7cfa-08d6bf5774d7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR11MB2919;
x-ms-traffictypediagnostic: BYAPR11MB2919:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <BYAPR11MB2919695C3D00646A6865501FD9280@BYAPR11MB2919.namprd11.prod.outlook.com>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(396003)(366004)(376002)(199004)(189003)(4326008)(86362001)(6116002)(2616005)(97736004)(186003)(446003)(486006)(68736007)(11346002)(26005)(5660300002)(93886005)(102836004)(6246003)(476003)(3846002)(6506007)(76176011)(53546011)(7736002)(81166006)(81156014)(54906003)(110136005)(25786009)(106356001)(8676002)(105586002)(8936002)(36756003)(71200400001)(71190400001)(66066001)(6436002)(316002)(2906002)(256004)(6486002)(58126008)(14454004)(229853002)(14444005)(53936002)(66574012)(478600001)(966005)(6512007)(30864003)(99286004)(6636002)(6306002)(54896002)(606006)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2919; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 1fnSijVGcLQAhls4b53QU/QvjW9N4yKZrmi6dlbqQNNwFrEZ1aTYZMLELmQMPuEKa2obYZxqrMIaknaHwDon4c6U/scjqInYfO+bDRagMY4/jvjkgfuXPgfhu8iTsu3HKGgFBitmjolXtKCdcvd4amOR6TUTvBT+49SO8GUZH1Q9snemgcJ1MofAMA6kXNHp5efrnP6ZJj0NOxkcs8fzyyd6R14gx1OKYPNofvr3qezRDP6W+se2kUZdAAHcCw8YVjqoZ3EPW04XZHwogZMNzNG9Vg2ZuvuGq4I5ZElcI45jMYPlcVxSRSe5bd77hIQgJsAdPWPGrcpydlH3taNO1M5+YbdagZf6Zw2GDIgm3mCt5xyvFQffbHPh1xCJtaPN3Gub8gSk0M8TurEhYlLTStgNADaGWue04cyO90ObS+s=
Content-Type: multipart/alternative; boundary="_000_D8D5F5102F2BC8sgundaveciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ee9e1bb-e0ad-456c-7cfa-08d6bf5774d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:59:26.1201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2919
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/yLI03-EV67znuHF0YwhiL9Mxh-c>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 14:59:35 -0000

If you go back and check 2017 archives, I did raise many of these issues.  But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is such a scope statement, it should clearly move these comments to the draft that defines how ND works for 802.11-OCB links.


https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw

https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA

Sri




From: its <its-bounces@ietf.org<mailto:its-bounces@ietf.org>> on behalf of Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Date: Friday, April 12, 2019 at 7:38 AM
To: Nabil Benamar <benamar73@gmail.com<mailto:benamar73@gmail.com>>, "Pascal Thubert (pthubert)" <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>, "its@ietf.org<mailto:its@ietf.org>" <its@ietf.org<mailto:its@ietf.org>>, "int-dir@ietf.org<mailto:int-dir@ietf.org>" <int-dir@ietf.org<mailto:int-dir@ietf.org>>, Nabil Benamar <n.benamar@est.umi.ac.ma<mailto:n.benamar@est.umi.ac.ma>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>>, Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

I am not following these discussions.  From my point of view, many of the discussions are totally out of scope for this document.

Some one needs to moderate these discussions.

Sri



From: its <its-bounces@ietf.org<mailto:its-bounces@ietf.org>> on behalf of Nabil Benamar <benamar73@gmail.com<mailto:benamar73@gmail.com>>
Date: Friday, April 12, 2019 at 7:34 AM
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>, "its@ietf.org<mailto:its@ietf.org>" <its@ietf.org<mailto:its@ietf.org>>, "int-dir@ietf.org<mailto:int-dir@ietf.org>" <int-dir@ietf.org<mailto:int-dir@ietf.org>>, Nabil Benamar <n.benamar@est.umi.ac.ma<mailto:n.benamar@est.umi.ac.ma>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>>, Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Hello Pascal,

I seconded Akex and would like to suggest you to add the missing text in the draft.

Best regards
Nabil



On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Hello Nabil.

You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…

Cheers,

Pascal

From: NABIL BENAMAR <n.benamar@est.umi.ac.ma<mailto:n.benamar@est.umi.ac.ma>>
Sent: lundi 8 avril 2019 17:53
To: Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; int-dir@ietf.org<mailto:int-dir@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; its@ietf.org<mailto:its@ietf.org>; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf..org>
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Yes definitely Alex....

There have been many reviews until now. This should be a late or final review.

On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>> wrote:

As a note: please improve the title of this.

It is not an early review.

It is a late review.

There have been several reviews of this document until here, and two shepherd reviews.

Alex
Le 04/03/2019 à 12:24, Pascal Thubert a écrit :

Reviewer: Pascal Thubert

Review result: Not Ready



Reviewer: Pascal Thubert

Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO

defines the use of L2 fields, what this spec enforces vs. recognizes as being

used that way based on IEEE work. The use of IPv6 ND requires a lot more

thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is

unclear. It seems that RSUs would have prefixes but that is not discussed.



I am an assigned INT and IOT directorates reviewer for <

draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written

primarily for the benefit of the Internet Area Directors. Document editors and

shepherd(s) should treat these comments just like they would treat comments

from any other IETF contributors and resolve them along with any other Last

Call comments that have been received. For more details on the INT Directorate,

see https://datatracker.ietf.org/group/intdir/about/



Majors issues

-----------------



“



o  Exceptions due to different operation of IPv6 network layer on

      802.11 than on Ethernet.



“

Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an

implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems

that you are defining the LLC. Figure 1 shows the proposed adaptation layer as

IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines

their use? If this spec defines a new LLC header (vs. how to use an IEEE field)

 then it should be very clear, and the newly defined fields should be isolated

from IEEE fields.



"

   The IPv6 packet transmitted on 802.11-OCB MUST be immediately

   preceded by a Logical Link Control (LLC) header and an 802.11 header.



"

Is there anything new or specific to OCB vs. classical 802.11 operations?

If/when this is echoing the IEEE specs then this text should not use uppercase

but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on

802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and

an 802.11 header ...'



different things? Why define both?



"   An 'adaptation' layer is inserted between a MAC layer and the

   Networking layer.  This is used to transform some parameters between

   their form expected by the IP stack and the form provided by the MAC

   layer.

"

Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is

this IETF business?



"

   The Receiver and Transmitter Address fields in the 802.11 header MUST

   contain the same values as the Destination and the Source Address

   fields in the Ethernet II Header, respectively.

"

Same,  this is IEEE game isn't it?



"



Solutions for these problems SHOULD

   consider the OCB mode of operation.

"

This is not specific enough to be actionable. I suggest to remove this sentence.

It would be of interest for the people defining those solutions to understand

the specific needs of OCB vs. Wi Fi, but I do not see text about that.



"



The method of forming IIDs

   described in section 4 of [RFC2464] MAY be used during transition

   time.

"

Contradicts section 4.3 that says

"

Among these types of

   addresses only the IPv6 link-local addresses MAY be formed using an

   EUI-64 identifier.

"



"



This

   subnet MUST use at least the link-local prefix fe80::/10 and the

   interfaces MUST be assigned IPv6 addresses of type link-local.

"

If this is conforming IPv6 then the MUST is not needed.



"

   A subnet is formed by the external 802.11-OCB interfaces of vehicles

   that are in close range (not by their in-vehicle interfaces).

"

Is the definition transitive? Do we really get a subnet?

 A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you

 talking about a link, rather?



"

   The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over

   802.11-OCB links.

"



IPv6 ND is not suited for a non-broadcast network. How does DAD work?

Maybe you could consider RFC 6775 / RFC 8505 instead.



"

In the moment the MAC address is changed

   on an 802.11-OCB interface all the Interface Identifiers of IPv6

   addresses assigned to that interface MUST change.

"

Why is that? This is unexpected, and hopefully wrong.



Minor issues

---------------



"   OCB (outside the context of a basic service set - BSS): A mode of

   operation in which a STA is not a member of a BSS and does not

   utilize IEEE Std 802.11 authentication, association, or data

   confidentiality.



   802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB

   attribute dot11OCBActivited is true.  Note: compliance with standards

   and regulations set in different countries when using the 5.9GHz

   frequency band is required.

"



Are these 2 different things?



"

Among these types of

 addresses only the IPv6 link-local addresses MAY be formed using an

  EUI-64 identifier.

"

This text should not be in a LL specific section since it deals with the other

addresses. Maybe rename the section to "addressing" or something?



"

   For privacy, the link-local address MAY be formed according to the

   mechanisms described in Section 5.2.

"

The MAY is not helpful. I suggest to remove the sentence that does not bring

value vs. 5.2



Could you make sections 4.3 and 4.5 contiguous?



"

If semantically

   opaque Interface Identifiers are needed, a potential method for

   generating semantically opaque Interface Identifiers with IPv6

   Stateless Address Autoconfiguration is given in [RFC7217]...



   Semantically opaque Interface Identifiers, instead of meaningful

   Interface Identifiers derived from a valid and meaningful MAC address

   ([RFC2464], section 4), MAY be needed in order to avoid certain

   privacy risks.



...



   In order to avoid these risks, opaque Interface Identifiers MAY be

   formed according to rules described in [RFC7217].  These opaque

   Interface Identifiers are formed starting from identifiers different

   than the MAC addresses, and from cryptographically strong material.

   Thus, privacy sensitive information is absent from Interface IDs, and

   it is impossible to calculate the initial value from which the

   Interface ID was calculated.



"

Duplicate and mis ordered text, isn't it?



" For this reason, an attacker may realize many

   attacks on privacy.

"

Do we attack privacy? Maybe say that privacy is a real concern, and maybe move

that text to security section?



"

   The way Interface Identifiers are used MAY involve risks to privacy,

   as described in Section 5.1.

"

Also duplicate



Nits

------



"

   IP packets MUST be transmitted over 802.11-OCB media as QoS Data

   frames whose format is specified in IEEE Std 802.11.

"

Please add link to the reference



" the 802.11 hidden node"

Do not use 802.11 standalone (multiple occurrences).

=> "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".



BCP 14 text:



Suggest to use this text:

“

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

   "OPTIONAL" in this document are to be interpreted as described in

   https://tools.ietf.org/html/bcp14 https://tools.ietf.org/html/bcp14

   [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they

   appear in all capitals, as shown here.



“



All the best



Pascal







_______________________________________________
its mailing list
its@ietf.org<mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its