Re: [Tsv-art] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Nabil Benamar <[e-mail]>]

Hi,

Quick answers inline

On Thu, Jul 4, 2019 at 3:42 PM Joerg Ott <[e-mail]> wrote:

> Hi,
>
> quick responses inline:
>
> >
> >     There are no clear transport issues in this document. The main
> >     relevant aspect would
> >     be MTU size, which is in line with standard IPv6. But the document
> >     discusses (section 4.2)
> >     that all IPv6 packets should be mapped to the same class of service.
> >     So, there is no
> >     service differentiation expected (diffserv, for example)?
> >
> >
> > We have not treated this detail in the current document.
>
> Indeed.  But the current document states that *all* IPv6 packets MUST be
> mapped to the same class of service.  You should leave room for refining
> this in the future since I would expect different traffic classes to
> appear.
>

We have not mentioned the class of service in the current document. We have
talked about address types.

>
> >     However, I do not consider the document to be really ready because
> >     of structure
> >     and writing clarity. This is surprising for version -46! There is a
> >     need for improvement
> >     to make the document properly understandable by the reader. I am
> >     actually wondering
> >     why this document is sent out for last call given the state the text
> >     is in.
> >
> >
> > The document will be proofred once again before  becoming an RFC.
>
> I am sorry but this is not acceptable.  You are asking other people
> to read the document and comment on it.  As such, we may certainly
> expect that what we get to review in last call is ready for RFC.
> This document clearly is not.
>

If you see any remaing typos or grmmatical errors, kindly point us to the
exact lines.

>
> >     Detailed comments:
> >
> >     In several places, the text reminds of patent jargon. Should I
> >     worry? There doesn't appear
> >     to be any IPR disclosure.
>
> Here, I'd really like to get an explicit response.
>

It is simple. There is no IPR!

>
> >     p5, 1st line: packet->packets
>

Corrected in -47

> >
> >
> > Are you referring to page 5 or paragraph 5?
>
> Page 5.  (Otherwise I would write para 5.)
>

Ok.

>
> >     The use of RFC 2026 language needs improvement.
> >
> >
> > I didn't get your point. Would you please clarify on how we can tackle
> > this issue, if any?
>
> RFC 2026 defines the proper use of MAY, MUST, SHOULD.  The document
> does not appear to be consistently using the capitalized words properly
> in all cases.  Just go through the document and check all pieces of
> this normative language.
>

Thank you for the reminder. However, we have already extinsively discussed
ALL of them in the mailing list. You may check -47.

>
> >     sect. 4.4: transition time is not defined >
> > The IP-OBUs that are based on embedded platforms can only use the former
> > (MAC-based) whereas more powerful platforms (native x86) can use
> > RFC8064.The majority of IP-OBUs are embedded platforms.  I'm not sure
> > whether they can use RFC8064.
>
> Ahh, this is what you mean by transition time.  I assumed that this
> would refer to the time moving from one point of attachment to another
> or so.  Can you say a bit more to make this clear?
>

Yes, I thought you were refering to  the length of time during which we
transition from the use of link-local addresses formed by deriving from
hardwired 48bit MAC identifiers, to the time where the link-local address
formed by deriving from more random identifiers (RFC8064).
Still, I'm not sure if IP-OBUs can use RFC8064! We need to ask in 6man.

> >
> >     "no generic meaning" -- means what?
> >
> >
> > No generic meaning' - means that the bits in the Interface Identifiers
> > are 'opaque'.  Earlier, the u/g bits in IID had a significance (it meant
> > 'unique/global'). A concept updated by RFC7136.
>
> Great. Then specify opaque -- generic has no meaning this in this
> context.
>


> Ok. I agree.



>
> >     This section is confusing. Please describe a concrete sequence of
> >     actions.
> >
> >
> > Would you show us how we can improve this section?
>
> Well, this should be up to the WG.  Just read it and try to
> understand what it says rather than confirming what you know.
>
> But, in general, as a reader I would expect to get a clear recipe
> with explicit steps.
>
> There are two kinds of identifiers: A and B.  If you need A, follow
> these steps: 1., 2., 3., ...  If you need B, then ...
> Here is some guidance when A or B is preferred.
>
> Most of this may be in the section but it is hard to extract.
>
> >     sect. 4.5: external references for standards are surely the right
> >     way. But
> >     the reader may benefit from some informal self-contained description.
> >
> >     sect. 4.5.2: anythings needs to be said about multicast reception?
>
We have already pointed out that "These issues may be
   exacerbated in OCB mode. A  Future improvement to this specification

   SHOULD consider solutions for these problems. "

> >
> >     sect 4.6: Clarify "A subnet may be formed over 802.11-OCB interfaces
> of
> >     vehicles that are in close range (not by their in-vehicle
> >     interfaces)." further.
>

in close range so that we can consider it's a P2P link.

> >
> >     sect. 5: explain briefly how certificates are supposed to work with
> >     variable addresses.
> >
> >     App. E: why would high mobility affect encapsulation"?
> >
> >     App. G: Ok to show complete packet formats. But then maybe also give
> >     specific examples?
> >     And why do you describe this as capturing what is received rather
> >     than how to construct
> >     something to sent out?
> >
> >     App. I: reliable multicast used incorrectly
> >     "TBD TBD TBD"
>
Corrected in -47

> >
> >     Nits: "mode.A", "; The", "on another hand", "At application layer"
> >     "attacker can therefore just sit in the near range of vehicles"
> >     "perform attacks without needing to physically break any wall."
> >     "embarking an"
> >     "outdoors public environments"
> >     "attacker sniffers"
> >     "indoor settings"
> >     "eventual conflicts"
> >     "internet"
> >     expand all acronyms, also in the appendices
>

Agreed. I will correct all these Nits. Thank you for pointing this out.

> >
> >     Why has sect. 5.3 bullets?
>

Ok. We can remove those bullets

>
> In short: there is A LOT of work to be done before this is ready.
>
> Jörg
>
>
>

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco