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 <carles.go...@upc.edu> Sent: Tuesday, 7 May 2024 07:37 To: Paul Kyzivat <pkyzi...@alum.mit.edu> Cc: Luigi IANNONE <luigi.iann...@huawei.com>; draft-ietf-6lo-path-aware-semantic-addressing....@ietf.org; 6lo@ietf.org 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 <pkyzi...@alum.mit.edu<mailto:pkyzi...@alum.mit.edu>> 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 -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
