Phelan, Tom wrote:
Hi Gorry,
This is a vastly improved version. Minus the sections at the end where
there are editor's notes and to-be-completed sections, I think you've
covered the subject completely and well.
>
Thanks.
> Some minor issues:
I'd like to consider moving the new service definitions to another
draft. This draft is already long enough and it'll be easier to digest
without that section. Also, creating those services raises some
security issues, and I don't want to drag this draft down with those
issues.
Understood. I suspect you'll raise that in the meeting.
Use of sender/receiver and client/server -- you tend to vary between
sender/client for one side and receiver/server for the other. Since the
client can be a receiver too (albeit for other messages than you're
usually discussing) I feel this gets confusing. I'd prefer to see it
stick to client/server; I think those terms tend to be less ambiguous.
For example, I think the title of section 3.3 should be "Using Service
Codes at the Server" rather than "at the Receiver".
Good comment, rev. 04 will have an update this wording in the way you
suggest.
Intro, 3rd paragraph:
"The use of Service Codes can assist in identifying the intended service
when the server by a Middleboxes"
Huh?
>
I also spotted that and one repeated UPDATE line - I'll fix these.
Same paragraph:
I think the middleboxes that should be most interested in service codes
are firewalls. I think it's less likely to be used by NATs. So maybe
reword that list to "primarily Firewalls, but possibly NATs, NAPTs,
etc." If you think saying "primarily" is too strong maybe just put
firewalls first.
Is this better: "The use of Service Codes can assist in identifying the
intended service by a firewall and may assist other Middleboxes (e.g., a
proxy server, network address translator (NAT) [RFC2663], NAT-PT
[RFC2766])."
Tom P.
Gorry
