Re: [Int-dir] link-local text (Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34)

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

 



At Tue, 16 Apr 2019 11:37:57 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:

> I must share that much text in earlier versions of this IP-over-OCB
> document did not have any capitalized keyword.  I was told we must use
> capitalized keywords otherwise it wont do.  Why RFC4291 is not told to
> use capitalized keywords?

I believe the use of capitalized words is quite strongly recommended
today, at least as a matter of practice.  As for RFC4291 (or for that
matter RFC8200), I don't know the real reason, but I suspect it's a
mixture of personal taste (of the author at that time) and historical
inertia.  The first version of these RFCs were written way before
RFC2119, at that point the convention of capitalized keywords were
less common.  We could have modernized these RFCs while we updated
them, but I *guess* the WG has just chosen to respect the seeming
intent of the original author of not using capitalized words.  (IIRC
there was even a discussion about this during the most recent
revision from RFC2460 to RFC8200).

> Your argumentation sounds reasonable.
>
> I thus propose in the IP-over-OCB document:
>
> OLD:
> >       A subnet is formed by the external 802.11-OCB interfaces of
> >       vehicles that are in close range (not by their in-vehicle
> >       interfaces).  This subnet MUST use at least the link-local
> >       prefix and the interfaces MUST be assigned IPv6 address(es)
> >       of type link-local.  All nodes in the subnet MUST be able to
> >       communicate directly using their link-local unicast
> >       addresses..
>
> NEW:
> >    A subnet is formed by the external 802.11-OCB interfaces of vehicles
> >    that are in close range (not by their in-vehicle interfaces).  A
> >    Prefix List conceptual data structure ([RFC4861] section 5.1) is
> >    maintained for each OCB interface.
> >
> >    All nodes in the subnet MUST be able to communicate directly using
> >    their link-local unicast addresses.

This is fine for me, although some others may rather find the phrase
"directly using" confusing.  If it's all about on-link determination,
you may just want to remove this sentence, which is also fine for me.

> > Perhaps it's not a well-defined term.  If you're concerned about the
> > terminology matter you can just say it's not a multi-link subnet.
>
> I propose this:
>
> NEW:
> >       The subnet is not a multi-link subnet.

Same for this one.  If you really want to note it's not a multi-link
subnet, this is fine for me.  But you may rather find it another
distracting (or even possibly controversial) point, and may rather not
to mention it.  That's fine for me, too.

--
JINMEI, Tatuya

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

  Powered by Linux