Original text:
addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs.  4. This section aims to improve understanding by describing a possible

Reviewer comments:
Thanks for doing this! I've left a few minor comments.
Just for transparency. Erik and I discussed this and made a few editorial changes.
thanks, was just trying to work on the changes here
Based on discussion in Singapore, the group decided to recommend (not require) that URLs use names that can be resolved from the public DNS (no split horizon, etc...). The content served from those URLs should also not be dependent on the network path, but instead the URL would include all information necessary to produce the resource.
i remember we were talking about primarily venue URL should be context free however, the architecture doc does not mention the venue URL (only portal URL) which section shall we add this context-free please? (maybe in section_pvd?) shall we also mention this in the api doc?
I think that NAME might want to think about what to include once we have text here. The text can be generic. I would suggest a new Section 3.5 as this relates to identification of UE. That is, you say that information presented in the API - and in particular URLs - need to include identification UE information. In particular, any information that is used from this context should not depend on ambient information, such as the remote address on a connection, as this information might be used by the UE on a different network interface. For example, a user might access venue information URLs from another network. You might also then mention that this might expose the service to spoofing or replay of that information in those cases. This might mean that though the URL might "work", it might not present all options. For instance, payment options might not be offered, or if they are, warnings might be shown that the payment is not for the current connection.
Thanks for doing this. This seems to accurately capture the outcome of the discussion we had.

Revised text:
addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The URLs provided in the API SHOULD contain all the information necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are expected to be resolved using public DNS. Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay attacks. </ins> 4. This section aims to improve understanding by describing a possible