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 <ott@xxxxxxxxx> 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 <ott@xxxxxxxxx
> <mailto:ott@xxxxxxxxx>> 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
> Tsv-art@xxxxxxxx
> 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
