Yes, Thanks a lot Paul. We will add text as discussed, making sure also your last concerns are addressed. You will check at the next round 😉
Ciao L. From: Carles Gomez Montenegro <[email protected]> Sent: Tuesday, 7 May 2024 07:37 To: Paul Kyzivat <[email protected]> Cc: Luigi IANNONE <[email protected]>; [email protected]; [email protected] Subject: Re: Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05 Hi Paul, Many thanks for your thoughtful review! Cheers, Shwetha and Carles (6lo WG chairs) On Mon, 6 May 2024 at 23:35, Paul Kyzivat <[email protected]<mailto:[email protected]>> wrote: Hi Luigi, Below I've edited out all the stuff that is settled and irrelevant to remaining issues. Then I inserted my comments. On 5/6/24 7:17 AM, Luigi IANNONE wrote: >>>> 2) ISSUE: Working of OT network domains ... > [LI] You got it right. What about the following (re-using part of your > wording): > > * In an idealized PASA-based OT domain, a leaf-node could be a field > device (sensor or actuator) that always connects to PLC serving as > last node forwarding traffic to/from the leaves, i.e. sensors and > actuators. Hence, the PLC will work as a PASA Router only > for field devices supporting IPv6. For field devices not supporting IPv6 > the PLC will assign PASA addresses for each of them, and then translate > between IPv6 packets and the device protocol, making the devices > appear as PASA Hosts within the enclosing PASA Domain. > > [LI] Clear enough? Yes, good. >>>> 4) ISSUE: Address Assignment > [LI] May be we should add a sentence after the FCFS policy. Something like: > > "Some deployments may have tighter constrains on the router selection, but > enforcing such selection is beyond the scope of this document." > > What do you think? I don't know. This is outside my depth unless I study up on the other documents in your WG. I looked briefly but it seemed like more than I wanted to take on for this review. By now I think you understand my concern. I leave it to you to decide if this is covered adequately among all your documents. >>>> 5) ISSUE: Root Node Address ... > [LI] Now I see you point. The reason why the root address is always 1 is > because of the question in issue 8. > In this way it is very easy to unpad the address, just drop all the leading > zeros. > I think is worth to add text to better highlight the exception of why the > root, while being a router, has the address 1. > We will add a sentence. Sounds good. Make it clear that the root node address MUST be "1". >>>> 6) ISSUE: Tree Address Assignment Function ... >> But it raises different questions in my mind: >> >> If all of these devices are stateful then there may be situations when a >> device is reset and forgets all that state. This is fine if every device >> in the domain is reset simultaneously. But if a subset of devices is >> reset there will be problems: >> >> If a host is reset it will request a new address from its old router. >> (Assuming it chooses the same router.) its old address becomes an >> orphan. Or is the router supposed to recognize the host and send back >> the old address? > > [LI] Good point. This must be covered in the GAAO document. The router needs > to store address assignments in non-volatile memory. IIUC you are saying that these issues are the responsibility of a different document. I leave that for you to sort out. >> If a router is reset, then it won't remember any of its children, but >> they will still remember it and won't have any reason to reconnect. > > [LI] Not sure I understand you here. Children can still re-register their > address since they remember. > [LI] I didn't see re-registering mentioned in this doc. Again I assume you have that covered in other documents. I think I am done now. I hope I've been more of a help than a pain. The usual policies for genart review assignments will probably mean I'll be back for a later review. See you then. :-) Thanks, Paul
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
