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

[Nabil Benamar <[e-mail]>]

I'm aware of this point. The thing is that I published -47 as a response
to Gen-ART reviewer for this draft. At the same time, we received your
feedback on -46!!


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

> Just one quick note: I am writing the TSV-ART review.  This means that I
> am not necessarily on the IPWAVE mailing list, so I am not following
> what you are discussing there.  It's good to see a new version -47
> having done already some fixed (I got asked to review -46 when the WG
> sent this off for last call).
>
> If you send out an incomplete document (such as -46) for review, you
> are wasting people's time because all those reviewers will have to go
> through yet another version. This is, simply put, not helpful.
>

I agree. However, I did send version -47 after the LAST CALL deadline which
was 26 June. I did not know that there will be other incoming reviews!!

>
> So, please, before the next version goes out for a last call, -5x or
> something, please make sure that this is in a shape that you could
> see published as is.
>

Thank you for the advice, but why necessairly -5x?

>
> Jörg
>
> On 04.07.19 22:31, Nabil Benamar wrote:
> > Hi,
> >
> > Quick answers inline
> >
> > On Thu, Jul 4, 2019 at 3:42 PM Joerg Ott <[e-mail]
> > <mailto:[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
> >
> >
> >
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art
> >
>


-- 

Best Regards

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