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

[Joerg Ott <[e-mail]>]

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.

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.

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
>