Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexandre:

Yes.  Once the WG sends the document to the IESG, there will be more review.  Resolving the current set of comments will put us in a much better place, and increase the number of people that are supporting the approach in the document.

Russ


> On Apr 8, 2019, at 9:09 AM, Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
> 
> 
> 
> Le 08/04/2019 à 14:58, Pascal Thubert (pthubert) a écrit :
>> Hello Alexandre
>> All the best,please see below
>> *From:*Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx>
>> *Sent:* lundi 8 avril 2019 17:01
>> *To:* Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; int-dir@xxxxxxxx
>> *Cc:* ietf@xxxxxxxx; its@xxxxxxxx; draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx
>> *Subject:* Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
>> As a note: please improve the title of this.
>> It is not an early review.
>> It is a late review.
>>  * In the context of document publication I believe this is coming
>>    before all the other areas directorates isn’t it. That’s what early
>>    means here…
> 
> Ah?
> 
> Should we expect more reviews from more directorates?
> 
> How about IESG?
> 
> Alex
> 
>> There have been several reviews of this document until here, and two shepherd reviews.
>> Alex
>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>    Reviewer: Pascal Thubert
>>    Review result: Not Ready
>>    Reviewer: Pascal Thubert
>>    Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO
>>    defines the use of L2 fields, what this spec enforces vs. recognizes as being
>>    used that way based on IEEE work. The use of IPv6 ND requires a lot more
>>    thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is
>>    unclear. It seems that RSUs would have prefixes but that is not discussed.
>>    I am an assigned INT and IOT directorates reviewer for <
>>    draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written
>>    primarily for the benefit of the Internet Area Directors. Document editors and
>>    shepherd(s) should treat these comments just like they would treat comments
>>    from any other IETF contributors and resolve them along with any other Last
>>    Call comments that have been received. For more details on the INT Directorate,
>>    seehttps://datatracker.ietf.org/group/intdir/about/
>>    Majors issues
>>    -----------------
>>    “
>>    o  Exceptions due to different operation of IPv6 network layer on
>>           802.11 than on Ethernet.
>>    “
>>    Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an
>>    implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems
>>    that you are defining the LLC. Figure 1 shows the proposed adaptation layer as
>>    IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines
>>    their use? If this spec defines a new LLC header (vs. how to use an IEEE field)
>>      then it should be very clear, and the newly defined fields should be isolated
>>    from IEEE fields.
>>    "
>>        The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>>        preceded by a Logical Link Control (LLC) header and an 802.11 header.
>>    "
>>    Is there anything new or specific to OCB vs. classical 802.11 operations?
>>    If/when this is echoing the IEEE specs then this text should not use uppercase
>>    but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on
>>    802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and
>>    an 802.11 header ...'
>>    different things? Why define both?
>>    "   An 'adaptation' layer is inserted between a MAC layer and the
>>        Networking layer.  This is used to transform some parameters between
>>        their form expected by the IP stack and the form provided by the MAC
>>        layer.
>>    "
>>    Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is
>>    this IETF business?
>>    "
>>        The Receiver and Transmitter Address fields in the 802.11 header MUST
>>        contain the same values as the Destination and the Source Address
>>        fields in the Ethernet II Header, respectively.
>>    "
>>    Same,  this is IEEE game isn't it?
>>    "
>>    Solutions for these problems SHOULD
>>        consider the OCB mode of operation.
>>    "
>>    This is not specific enough to be actionable. I suggest to remove this sentence.
>>    It would be of interest for the people defining those solutions to understand
>>    the specific needs of OCB vs. Wi Fi, but I do not see text about that.
>>    "
>>    The method of forming IIDs
>>        described in section 4 of [RFC2464] MAY be used during transition
>>        time.
>>    "
>>    Contradicts section 4.3 that says
>>    "
>>    Among these types of
>>        addresses only the IPv6 link-local addresses MAY be formed using an
>>        EUI-64 identifier.
>>    "
>>    "
>>    This
>>        subnet MUST use at least the link-local prefix fe80::/10 and the
>>        interfaces MUST be assigned IPv6 addresses of type link-local.
>>    "
>>    If this is conforming IPv6 then the MUST is not needed.
>>    "
>>        A subnet is formed by the external 802.11-OCB interfaces of vehicles
>>        that are in close range (not by their in-vehicle interfaces).
>>    "
>>    Is the definition transitive? Do we really get a subnet?
>>      A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you
>>      talking about a link, rather?
>>    "
>>        The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
>>        802.11-OCB links.
>>    "
>>    IPv6 ND is not suited for a non-broadcast network. How does DAD work?
>>    Maybe you could consider RFC 6775 / RFC 8505 instead.
>>    "
>>    In the moment the MAC address is changed
>>        on an 802.11-OCB interface all the Interface Identifiers of IPv6
>>        addresses assigned to that interface MUST change.
>>    "
>>    Why is that? This is unexpected, and hopefully wrong.
>>    Minor issues
>>    ---------------
>>    "   OCB (outside the context of a basic service set - BSS): A mode of
>>        operation in which a STA is not a member of a BSS and does not
>>        utilize IEEE Std 802.11 authentication, association, or data
>>        confidentiality.
>>        802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>>        attribute dot11OCBActivited is true.  Note: compliance with standards
>>        and regulations set in different countries when using the 5.9GHz
>>        frequency band is required.
>>    "
>>    Are these 2 different things?
>>    "
>>    Among these types of
>>      addresses only the IPv6 link-local addresses MAY be formed using an
>>       EUI-64 identifier.
>>    "
>>    This text should not be in a LL specific section since it deals with the other
>>    addresses. Maybe rename the section to "addressing" or something?
>>    "
>>        For privacy, the link-local address MAY be formed according to the
>>        mechanisms described in Section 5.2.
>>    "
>>    The MAY is not helpful. I suggest to remove the sentence that does not bring
>>    value vs. 5.2
>>    Could you make sections 4.3 and 4.5 contiguous?
>>    "
>>    If semantically
>>        opaque Interface Identifiers are needed, a potential method for
>>        generating semantically opaque Interface Identifiers with IPv6
>>        Stateless Address Autoconfiguration is given in [RFC7217].
>>        Semantically opaque Interface Identifiers, instead of meaningful
>>        Interface Identifiers derived from a valid and meaningful MAC address
>>        ([RFC2464], section 4), MAY be needed in order to avoid certain
>>        privacy risks.
>>    ...
>>        In order to avoid these risks, opaque Interface Identifiers MAY be
>>        formed according to rules described in [RFC7217].  These opaque
>>        Interface Identifiers are formed starting from identifiers different
>>        than the MAC addresses, and from cryptographically strong material.
>>        Thus, privacy sensitive information is absent from Interface IDs, and
>>        it is impossible to calculate the initial value from which the
>>        Interface ID was calculated.
>>    "
>>    Duplicate and mis ordered text, isn't it?
>>    " For this reason, an attacker may realize many
>>        attacks on privacy.
>>    "
>>    Do we attack privacy? Maybe say that privacy is a real concern, and maybe move
>>    that text to security section?
>>    "
>>        The way Interface Identifiers are used MAY involve risks to privacy,
>>        as described in Section 5.1.
>>    "
>>    Also duplicate
>>    Nits
>>    ------
>>    "
>>        IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>>        frames whose format is specified in IEEE Std 802.11.
>>    "
>>    Please add link to the reference
>>    " the 802.11 hidden node"
>>    Do not use 802.11 standalone (multiple occurrences).
>>    => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>>    BCP 14 text:
>>    Suggest to use this text:
>>    “
>>        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>        "OPTIONAL" in this document are to be interpreted as described in
>>        https://tools.ietf.org/html/bcp14  https://tools.ietf.org/html/bcp14
>>        [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they
>>        appear in all capitals, as shown here.
>>    “
>>    All the best
>>    Pascal
> 
> _______________________________________________
> its mailing list
> its@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/its





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux