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.
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.
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.
p5, 1st line: packet->packets
Are you referring to page 5 or paragraph 5?
Page 5. (Otherwise I would write para 5.)
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.
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?
"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.
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?
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.
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"
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
Why has sect. 5.3 bullets?
In short: there is A LOT of work to be done before this is ready.
Jörg
