Done 😊 many thanks, Tom.
> -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: lundi 21 novembre 2022 18:08 > To: Pascal Thubert (pthubert) <pthub...@cisco.com>; Mark Smith > <markzzzsm...@gmail.com>; carles.go...@upc.edu > Cc: 6lo@ietf.org; 6man WG <i...@ietf.org> > Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast- > registration-11 > > From: Pascal Thubert (pthubert) <pthub...@cisco.com> > 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 <6lo-boun...@ietf.org> On Behalf Of tom petch > > Sent: samedi 19 novembre 2022 13:47 > > To: Pascal Thubert (pthubert) <pthub...@cisco.com>; Mark Smith > > <markzzzsm...@gmail.com>; carles.go...@upc.edu > > Cc: 6lo@ietf.org; 6man WG <i...@ietf.org> > > Subject: Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast- > > registration-11 > > > > From: Pascal Thubert (pthubert) <pthub...@cisco.com> > > 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 <ie...@btconnect.com> > > > Sent: jeudi 17 novembre 2022 17:53 > > > To: Pascal Thubert (pthubert) <pthub...@cisco.com>; Mark Smith > > > <markzzzsm...@gmail.com>; carles.go...@upc.edu > > > Cc: 6lo@ietf.org; 6man WG <i...@ietf.org> > > > Subject: Re: [IPv6] WG Last Call on > > > draft-ietf-6lo-multicast-registration- > > > 11 > > > > > > From: ipv6 <mailto:ipv6-boun...@ietf.org> on behalf of Pascal > > > Thubert > > > (pthubert) <mailto:pthubert=40cisco....@dmarc.ietf.org> > > > 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:ipv6-boun...@ietf.org> 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:carles.go...@upc.edu<mailto:carles.go...@upc.edu>> 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:i...@ietf.org<mailto:i...@ietf.org> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
