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

Abdussalam Baryun <abdussalambaryun@gmail.com> Sat, 13 April 2019 22:09 UTC

Return-Path: <abdussalambaryun@gmail.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 5D3131201B6; Sat, 13 Apr 2019 15:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WWdOb5hKjWdE; Sat, 13 Apr 2019 15:09:31 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0081201D2; Sat, 13 Apr 2019 15:09:31 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id v7so10841397oie.8; Sat, 13 Apr 2019 15:09:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IbWOD+YZkxM+v2YwhVXJJ9fi8qivJWfR+mPmxieBAsw=; b=nfQAp3TvNfLCCIMt5RTy5e2Mabc1vv1qCv/ulbPN7ZnPll7eeDipXQlB0QSqjT7rez cjO2LN6ti3Y1Eu0sFIXn2aYiYNdIdaxuy88Zsi1+na16R7wYo8W1Eqgbm5qP8Zaanb1b xUqL9BzD+smzy3yBgDRPHA5nJ8C9HDvfwgH1HXadQlJUcgdwkmG4RkbA20Ef+/QzHqWD 9xW7pPcLec0osJIwV5p9y0UsVMgucrumO8zFOPI8xAFDEgOnQ3QSrpXNnKI+JbJtOeX4 xdXlINTrIU6as0DhQiPrm7F8rl1FORlMFOeAw8jlFzKDnMbgT05+IwWr4pcjNRPClo6q xl0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IbWOD+YZkxM+v2YwhVXJJ9fi8qivJWfR+mPmxieBAsw=; b=a4gXiTJUlOKUf5wpQdGLYiFs5xj0iHWexwTpar4USBQ+o5K18ooWC/ys3FlT30mMTz O7lyCc3dCTi0xkNjnW6kVW+gxyZF2ogsTmi23zbnfwgTJnQfEVuy31Usk7/Gw3Nz7jib 2hq+WoUlSSodZK9dBAibtOiLPBuMzYdQsBzRVu0HaSGrdrlvx0uUpRcT70ZI+i0gX89C C0XC/5cvYGMVlaN0rgrqLJyzF5G8I/uT++t1a5uQ1JG0WCtEusqcgSQxsD3rlqatwhHf GSqOgylrje3vUPSkGXdaKzPPx9+yB24YHmRSAWX4F4OXSREiPqamu0jUkJCJmHmARiRb nNrw==
X-Gm-Message-State: APjAAAWchjLdYlxyHNS1yYd72ckt+zqCtpwRC8XrjTsClmL3oQjDpAcO 7CbXZ0q5rOcPhUbWIvJ87s4eUhQKOBgKNpaT3EU=
X-Google-Smtp-Source: APXvYqx+1aSQ/iju3mymYEBC4l0FGFQ+RYpBcRbVTEKLY4nfjFvQ2LQ+rxsya2EKGvSQxKVYMNJaF4pxM1wL9AGLOKM=
X-Received: by 2002:aca:b587:: with SMTP id e129mr13765630oif.143.1555193371049; Sat, 13 Apr 2019 15:09:31 -0700 (PDT)
MIME-Version: 1.0
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> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com>
In-Reply-To: <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Sun, 14 Apr 2019 00:09:10 +0200
Message-ID: <CADnDZ88MOMN66-Xejim8Mx+o34H6NLFjEyD3NkCEZoyKjy=yrw@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Nabil Benamar <benamar73@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 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>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007045a3058670ace7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/TeH_cmYOSp3GXpmuhaophINkXRA>
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: Sat, 13 Apr 2019 22:09:34 -0000

On Fri, Apr 12, 2019 at 10:28 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
> > 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.
>
> This is of course possible. In general the IETF hasn't done that, but has
> followed the lead set by RFC 2464 with the complete specification of
> IPv6-over-foo in one document.
>

yes this draft-38 is similar to rfc2464.


> However, I don't believe that publishing an RFC about the frame format
> without *simultaneously* publishing an RFC about ND etc would be a good
> idea.


that was done and was good idea by IETF in publishing (RFC2460,
RFC2461,RFC2373),  and (RFC3513, RFC4861,RFC8200), which they are separate
of same IPv6 communication. IMHO it is not good idea to separate IPv6
related protocols because it gets complicated if in one, and it has
different scenarios and use cases. Similarly in ITS if using that IPv6 over
OCB it is good to separate if possible.



> That would leave developers absolutely unable to write useful
> code, and might easily lead to incompatible implementations.


There are many SDOs that are standardizing for ITS so we need
to specify work, otherwise the developer will not wait for us but will do
useful work without us.

AB