Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi François,

Thanks for your comments. Please, see mine inline below.

On Mon, 2018-01-29 at 09:52 -0500, François Simon wrote:
> My comments are within the text [Fygs.......].
> Sincerely,
> Francois Simon
> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Carlos Jesús
> Bernardos Cano
> Sent: Monday, January 29, 2018 4:24 AM
> To: [e-mail]; [e-mail]
> Cc: Russ Housley <[e-mail]>; [e-mail]
> Subject: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-
> 80211ocb-12
> Hi,
> (Suresh, please check a question that I make below.)
> I'm the doc shepherd of this draft. I've performed a review and I
> have the following comments:
> - The document's intended status is "Standards Track", but the way it
> is written and most of its content looks more like an
> Informational/BCP kind of document. There no normative text
> applicable to what needs to be done to transmit IPv6 packets over
> IEEE 802.11-OCB. This has been discussed during the F2F meeting in
> Singapore and needs to be tackled.
> In many parts of the document, it seems that the main conclusion is
> that "nothing different from IPv6 over IEEE 802.11 needs to be done
> for IEEE 802.11-OCB" (at least for the current scope of the doc). If
> that is the case, maybe the document should be Informational and
> reflect just some recommendations. If there is something else that
> needs to be done, then it has to be more clearly stated (using
> normative text).
> @Suresh, can you provide some guidance on this point?
> - The abstract mentions that in order to transmit IPv6 packets on
> IEEE 802.11-OCB, "there is a need to define a few parameters such as
> the supported Maximum Transmission Unit size on the 802.11-OCB link,
> the header format preceding the IPv6 header, the Type value within
> it, and others". But the MTU part of the draft does not use any
> normative text,  the header format is exactly the same than for IEEE
> 802.11, as the type value.
> - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet.
> The first one is not different from regular 802.11, but for the
> second one, the document only provides recommendations.
> - I always thought that "WiFi" does not stand for "Wireless
> Fidelity".
> See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html
> [Fygs: It does stand for "Wireless Fidelity"]

[Carlos] I'm not an expert on the matter, but people I asked told me
that it does not. Not a major issue anyway...

> - The use of MAY (to be interpreted as in RFC2119) in the terminology
> section does not seem appropriate to me. I don't think normative text
> applies to whether an OBRU may be ab IP router.
> - In the terminology section, the OBU term is mentioned to be defined
> outside the IETF. This is fine, but we have to provide a reference.
> And even with that, it would not harm to include some short
> definition to provide context. The RSU term is also defined outside
> the IETF and there is quite a lot of text provided (I think the
> relevant part is the last sentence, the one starting with "The
> difference between..."). Both terms should be handled in the same
> way.
> [Fygs: The definitions was issued by the FCC 20 years ago.  I have
> already provided that information and references multiple times.]

[Carlos] So then it should be easy to close this comment.

Thanks,

Carlos

> - In section 3, it is mentioned that "the operating environment
> (vehicular networks) brings in new perspectives" --> which are those
> (that are covered/tackled by the document?
> - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500
> octects. If that is what is meant, this is really a normative thing
> that should be written using normative text. If it is just a
> recommendation, then this should be clearly written as such.
> - All the text of section 4.2.1 is not normative, but more a report
> of what is done today in existing implementations. Is there any
> different there that is specific of 802.11-OCB?
> - All subsections 4.x seem informative, not normative.
> - The privacy part of section 5 is important, as it impacts the
> operation of IPv6 over this type of networks, so I think this
> deserves more attention.
> - In section 5, "amd" --> "and".
> - In section, H.1, more details about how the captures were obtained
> should be provided (HW, SW, etc.).
> Authors, please respond to my questions/comments and address them in
> a new version of the document.
> Thanks,
> Carlos
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its