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

["Pascal Thubert (pthubert)" <[e-mail]>]

Done 😊 many thanks, Tom.

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: lundi 21 novembre 2022 18:08
> 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: 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-
> regis
> > > tr
> > > 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