Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[tom petch <[e-mail]>]

From: Pascal Thubert (pthubert) <[e-mail]>
Sent: 21 November 2022 13:11

Many thanks Tom.

As a reference for the reader since it is unpublished, the current title in github is:
"
     IPv6 Neighbor Discovery Multicast and Anycast Address Listener
                              Subscription
"
And the current abstract is as follows:
"
   This document updates RFC 8505 to enable a listener to subscribe an
   IPv6 anycast or multicast address; the draft updates RFC 6550 (RPL)
   to add a new Non-Storing Multicast Mode and a new support for anycast
   addresses in Storing and Non-Storing Modes.  This document extends
   RFC 9010 to enable the 6LR to inject the anycast and multicast
   addresses in RPL.
"
>
> Equally I found Multicast on its own adequate,  Yes the I-D caters for
> Anycast and that is in the Abstract but I query the need for it in the
> Title- a reader  might well wonder about the latter and find the answer in
> the Abstract.

Pardon my non-native limitation here; I read this as:
 "anycast is superfluous, find it in the abstract" is that correct?
The source of confusion is that your initial proposal was
"Subscribing to IPv6 Broadcast and Multicast Addresses in a 6LN Network"
Which clearly was a typo so I read " IPv6 Broadcast" -> "IPv6 Anycast"
and I applied that. Also, Mark recommended to place Anycast in the title.

> My thought remains that the Title should lead into the Abstract, as the
> Abstract leads into the document but in neither case will the former cover
> all that the latter does.

Makes full sense to me.

> So with no explicit mention of ND in the Abstract I query its appearance in
> the Title.

I guess this calls for a change in the abstract to mention it.
The tension here is that we need to list RFC 8505 in the abstract because we
extend it. RFC 8505 is "Registration Extensions for IPv6 over 6LoWPAN Neighbor
Discovery" so using those words in full would be cumbersome.

> I think that the Title of the RFC needs to indicate the type of network
> involved and did look at other RFC to see how this network is referred to
> and see much usage of Low-Power Wireless Personal Area Networks (6LoWPANs)
> which seems cumbersome to me but suggests that there is no recognised,
> shorter tag which might be used:-(.

True; and even worse, LoWPAN in IEEE parlance is 802.15.4 only.
But 6LoWPAN ND works on any link I'm aware of. So the term 6LoWPAN ND is
Highly misleading.

>
> As you gather, I think that titles matter, as do abstracts, that they
> should be short enough to read, recognise or remember but should not be
> overloaded with all the possible semantics.
>
> By contrast, I care little about the title of the I-D which almost vanishes
> once the RFC is published; for me, many I-D titles are too cumbersome
> although this one is just fine (no need for Anycast or ND in it:-).

I appreciate that, Tom.

From the discussion above I'm not sure I should take anycast out of the title.
I made the changes below:

     IPv6 Neighbor Discovery Multicast and Anycast Address Listener
                              Subscription

   This document updates the 6LoWPAN extensions to IPv6 Neighbor
   Discovery (RFC 8505) to enable a listener to subscribe an IPv6
   anycast or multicast address; the draft updates RPL (RFC 6550) to add
   a new Non-Storing Multicast Mode and a new support for anycast
   addresses in Storing and Non-Storing Modes.  This document extends
   RFC 9010 to enable the 6LR to inject the anycast and multicast
   addresses in RPL.

<TPn>
Well, thank you for considering my suggestions.  I will shut up now about the Title but with a couple of editorial thoughts on the Abstract.   'the draft' might be better as 'the document'  and do you 'subscribe' addresses or 'subscribe to'?  I think the latter.

Tom petch


Many thanks,

Pascal


> -----Original Message-----
> From: 6lo <[e-mail]> On Behalf Of tom petch
> Sent: samedi 19 novembre 2022 13:47
> To: Pascal Thubert (pthubert) <[e-mail]>; Mark Smith
> <[e-mail]>; [e-mail]
> Cc: [e-mail]; 6man WG <[e-mail]>
> Subject: Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
>
> From: Pascal Thubert (pthubert) <[e-mail]>
> Sent: 18 November 2022 10:56
>
> Hello Tom:
>
> I agree nunicast is weird and I'm not inclined to use it.
>
> About your proposed "6LN network": we do not have that language so far. We
> have LLN but that does not imply 6LoWPAN ND, and RFC 8505 does not imply
> constrained networks. It is a stateful AAD operation, it consumes less
> resource so it works EVEN in constrained devices and networks. It's an EVEN
> not an ONLY. It makes ND greener. As an L3 function, stateful AAD should be
> abstract to the lower layers, to the network they are used in, to the
> hardware in general. And it is, more than SLAAC actually, since SLAAC is
> limited to certain abstract topologies (P2P and NBMA).
>
> Also there's a semantic confusion between "constrained node" and "node that
> supports 6LoWPAN HC" or "node that supports 6LoWPAN ND". In this
> specification, we mean the latter, so we really refer to the L3 function
> not a type of nodes. In other words, we use 6LN and 6LR as nodes that
> support the L3 functions that 6LoWPAN defined as part of IPv6 ND for the
> host and the router side respectively to provide stateful AAD. Maybe we
> should have introduced new terms but at this point it makes sense reusing
> the language in RFC 8505 that we are extending.
>
> Considering the number of ND broadcasts we observe it's probably time we
> sunset SLAAC in any large network. Our small contribution to the planet if
> you like. But dropping AAC with SLAAC would be throwing the baby with the
> water of the bath. RFC 8505 makes AAD greener and more deterministic by
> avoiding the broadcasts in SLAAC and providing a contract between the host
> and the router for address ownership and usability. As you've seen recently
> on v6ops ML, SLAAC has a huge issue there and we're now hitting that wall.
>
> <tp>
> Pascal
>
> Thank you for the comprehensive reply.
>
> My thought remains that the Title should lead into the Abstract, as the
> Abstract leads into the document but in neither case will the former cover
> all that the latter does.
> So with no explicit mention of ND in the Abstract I query its appearance in
> the Title.
>
> Equally I found Multicast on its own adequate,  Yes the I-D caters for
> Anycast and that is in the Abstract but I query the need for it in the
> Title- a reader  might well wonder about the latter and find the answer in
> the Abstract.
>
> I think that the Title of the RFC needs to indicate the type of network
> involved and did look at other RFC to see how this network is referred to
> and see much usage of Low-Power Wireless Personal Area Networks (6LoWPANs)
> which seems cumbersome to me but suggests that there is no recognised,
> shorter tag which might be used:-(.
>
> As you gather, I think that titles matter, as do abstracts, that they
> should be short enough to read, recognise or remember but should not be
> overloaded with all the possible semantics.
>
> By contrast, I care little about the title of the I-D which almost vanishes
> once the RFC is published; for me, many I-D titles are too cumbersome
> although this one is just fine (no need for Anycast or ND in it:-).
>
> Tom Petch
>
> All the best,
>
> Pascal
>
>
>
> > -----Original Message-----
> > From: tom petch <[e-mail]>
> > Sent: jeudi 17 novembre 2022 17:53
> > To: Pascal Thubert (pthubert) <[e-mail]>; Mark Smith
> > <[e-mail]>; [e-mail]
> > Cc: [e-mail]; 6man WG <[e-mail]>
> > Subject: Re: [IPv6] WG Last Call on
> > draft-ietf-6lo-multicast-registration-
> > 11
> >
> > From: ipv6 <mailto:[e-mail]> on behalf of Pascal Thubert
> > (pthubert) <mailto:pthubert=[e-mail]>
> > Sent: 17 November 2022 12:02
> >
> > Done 😊
> >
> > <tp>
> > Piling nouns in a  heap often does not work well in English and may be
> > ambiguous.  The Abstract seems clear but I would not have expected it
> > from the title, old or new.
> >
> > Neighbor Discovery is not in the Abstract and I do not think it adds
> > to the Title.  The Abstract has subscribe as a verb and that seems to me
> spot on.
> >
> > The Abstract has 6LR without expansion but it does narrow the scope
> > from all aspects of ND.
> >
> > Hence I suggest something along the lines of Subscribing to IPv6
> > Broadcast and Multicast Addresses in a 6LN Network.
> > In passing, I saw recently the term 'nunicast' and thought it ugly and
> > incomprehensible.  It got revised to non-unicast which I understood
> > and then to multicast and broadcast.
> >
> > Tom Petch
> >
> > From: ipv6 <mailto:[e-mail]> On Behalf Of Mark Smith
> > Sent: jeudi 17 novembre 2022 2:18
> >
> > Hi,
> >
> > I think the naming needs to change now that it is also doing anycast,
> > to something like "IPv6 Neighbor Discovery Multicast and Anycast
> > Address Listener Subscription".
> >
> > I think anycast is a different and distinct type of communication to
> > multicast, and is in the middle between unicast and multicast:
> >
> > i.e. unicast = 1 to 1; anycast = 1 to 1 of any/many; multicast = 1 to
> > many;
> >
> > Regards,
> > Mark.
> >
> >
> >
> > On Thu, 17 Nov 2022, 00:23 Carles Gomez Montenegro,
> > <mailto:[e-mail]<mailto:[e-mail]>> wrote:
> > Dear 6lo WG,
> >
> > (CC'ing 6man.)
> >
> > This message initiates WG Last Call on the following document:
> >
> > "IPv6 Neighbor Discovery Multicast Address Listener Subscription"
> > https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registr
> > ation-11
> >
> > The Last Call will end on Wednesday, 30th of November.
> >
> > Please provide your feedback on this document on the mailing list.
> > Short confirmation messages such as "it looks fine" are also welcome.
> >
> > Thanks,
> >
> > Shwetha and Carles
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > mailto:[e-mail]<mailto:[e-mail]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo