Dear Jason, Thank you for your comments and our apologies for the delay to get back to you
We are currently preparing the next revision of the draft. We have taken into account some of your proposed modifs (please see inline). Cheers, Med ________________________________ De : Jason Livingood [mailto:[email protected]] Envoyé : lundi 22 mars 2010 02:57 À : [email protected]; Reinaldo Penno; BOUCADAIR Mohamed NCPI/NAD/TIP; [email protected] Objet : Feedback on draft-wing-softwire-port-control-protocol-01 I thought I'd send over some feedback re this draft. Feel free to ignore some or all of my feedback. :-) 1 - Section 2 - Requirements I like the requirements but find it increasingly useful when documents call out requirements in a more direct fashion. Meaning, instead of Section 2 having a general list of 15 items you could call the out as REQ1 to REQ15. This is of course a matter of personal preference of course. If you use XML for your I-Ds, you could use this kind of list style: <list style="format REQ%d:" counter="protocol_requirements_count"> [Med] Done. 2 - Requirement #2: Nothing to change but my expectation is that this can handle into the 10s of thousands to 100s of thousands of customers. [Med] We added "(e.g., 10s of thousands to 100s of thousands of customers)." to R4. 3 - Req 3: protocol semantics is --> protocol semantics are ? [Med] Changed to "the protocol semantics must be independent of the IP version used for transport" 4 - Req 4: reword (awkward) --> allows graceful definition of... [Med] Done. 5 - Re 7: reword: ...can even be notified to a client --> ...can even be communicated to a client [Med] Done. 6 - Req 8: ...detect if port control server --> ...detect if the port control server [Med] Done. 7 - Req 9: either "an" existing mapping or "existing mapping(s)" -- based on your singular usage of mapping elsewhere, I'd suggest adding "an" 8 - Seeing Terminology in Section 3, I wonder if it makes sense to place the terminology before the requirements (which may argue for splitting section 2 into Section 2 - Scope, then Section 3 - Terminology, then Section 4 - Protocol Requirements). In the terminology section, it'd be helpful to have either direct terms or references relating to NAT64, NAT44, CP Router, and perhaps even NAT itself (some of this is in place already in your doc). Would also be nice to define stuff like Port Control Server, Port Requestor, etc. (or whatever terms you prefer for these elements), which you touch on in Section 5 (so perhaps a mention that the definitions of specific functional elements X, Y, and Z can be found in Section XX - as an internal document reference). A separate debate is over the use of CP router vs. home gateway vs. whatever, but that's not essential to continued work on the other points of your document for now. 9 - Req 12 and Req 14: "NATted environments" seems awkward, as it essentially = Network Address Translationed environments. I may recommend the simpler "NAT environments" or "environments using NAT" as an alternative [Med] Changed to "NAT-based environments". 10 - ADD new Req: "Ability to set a Time to Live (TTL) or timer on the port assignment, after which time the mapping is deleted (destroyed);" I would also then add one immediately after this: "Ability to communicate the TTL for a given mapping from the Port Control Server to the Port Requestor;" (you describe Mapping TTL as the Port Mapping Lifetime in 7.1.2 and removal as Port Mapping Destruction in 7.1.4) [Med] Done: R10: Ability to set a validity timer on the port mapping assignment, after which the mapping is deleted; R11: Ability to communicate the validity timer for a given port mapping from the server to the client; 11 - Req 14: Recommend references be added for UPnP IGD and NAT-PMP 12 - Section 6: Discovery - may want to add "This list is for example purposes only and shall not restrict the potential methods for discovery." This would make it more clear that new discovery methods may be used over time, and therefore that the list is non-exclusive. [Med] In the new revision of the draft, we make a recommendation for the discovery methods. 13 - Section 7.1.1, Note-4: Interesting question re challenge/response (to which I don't have a comment at the moment). At some point I think we should collectively give some thought to avenues for abuse. [Med] Agreed. 14 - Section 7.1.8: I could envision an eventual desire for more specific result codes relating to errors and other conditions. Thus, while 3-Deleted my suffice for now, it may be nice to have that result be, say, 300. Thus, eventually you may have 301-Deleted-TTL expired, and 302-Deleted-AtClientRequest, and 303-Deleted-InternalError, etc. This could be more helpful from an operations standpoint. For example, I may want to monitor for 303 responses (in my example) and alarm if I see any or if it exceeds a certain threshold. Similarly, the 4 - Out of Resources result may eventually have sub-variants like -Memory, -Storage, -Bandwidth, -whatever. The specific codes desired may only be learned upon implementation of the protocol, so I suppose I am simply suggesting you build in the ability to deliver more detailed result codes later, that are still within the general categories you have laid out in the I-D. [Med] Not taken into account yet, but we will consider it. 15 - Section 8.1, Part 1: You repeat "a request" in the 1st sentence [Med] Removed Regards, Jason ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
