-
Notifications
You must be signed in to change notification settings - Fork 2
Mohamed Boucadair's review #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
EskoDijk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @marco-tiloca-sics , proposed a few sentence edits - rest is ok!
Co-authored-by: Esko Dijk <EskoDijk@users.noreply.github.com>
Co-authored-by: Esko Dijk <EskoDijk@users.noreply.github.com>
Co-authored-by: Esko Dijk <EskoDijk@users.noreply.github.com>
EskoDijk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason I don't see my prior comments anymore here, but I'll just approve assuming it's ok now.
boucadair
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank for meticulously tracking review points.
Look good to me. I have one minor suggestion, but I'm OK even without it.
|
|
||
| In case a single client has sent multiple group requests and concurrent CoAP transactions are ongoing, the responses received by that client are matched to an active request using only the Token value. Due to UDP level multiplexing, the UDP destination port number of the response MUST match to the client endpoint's UDP port number, i.e., to the UDP source port number of the client's request. | ||
|
|
||
| Note that some responses to a group request might be filtered out and not reach the client if a NAT device is used with restrictive filtering in place. For example, this is the case if the NAT device employs "Endpoint-Dependent Filtering" (see {{Section 2.6 of RFC5128}}), i.e., the combination of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in {{Section 5 of RFC4787}}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Note that some responses to a group request might be filtered out and not reach the client if a NAT device is used with restrictive filtering in place. For example, this is the case if the NAT device employs "Endpoint-Dependent Filtering" (see {{Section 2.6 of RFC5128}}), i.e., the combination of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in {{Section 5 of RFC4787}}. | |
| Note that some responses to a group request might be filtered out and not reach the client if a NAT device is used with restrictive filtering in place. For example, this is the case if the NAT device employs "Address and Port-Dependent Filtering" (see {{Section 5 of RFC4787}}), i.e., the combination of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in {{Section 5 of RFC4787}}. |
The OLD is OK but better to use BEHAVE terms as these are well-established in the industry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@boucadair Thanks, I like this suggestion. Will be included!
This PR addresses the review from Mohamed Boucadair archived at https://mailarchive.ietf.org/arch/msg/core/6bjFRbSwzAvfdQqupIn9hCxB_OA/
(The separate PR #56 tracks the updates that address the comment on "dual-stack" and on the relation between application groups and CoAP groups)