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"> 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. 3 Req 3: protocol semantics is --> protocol semantics are ? 4 Req 4: reword (awkward) --> allows graceful definition of... 5 Re 7: reword: ...can even be notified to a client --> ...can even be communicated to a client 6 Req 8: ...detect if port control server --> ...detect if the port control server 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 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) 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. 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. 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. 15 Section 8.1, Part 1: You repeat ³a request² in the 1st sentence Regards, Jason
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
