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-registration-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
