Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-behave-v6v4-xlate-stateful-11
Hi Peter, Thanks for the review. all comments have been addressed, see log below. El 16/06/10 0:09, McCann Peter-A001034 escribió: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-behave-v6v4-xlate-stateful-11 Reviewer: Pete McCann Review Date: 2010-06-15 IETF LC End Date: 2010-06-15 IESG Telechat date: unknown Summary: Some bugs need fixing before publication Major issues: none Minor issues: Section 1.2.1: The IPv4 address pool is a set of IPv4 addresses, normally a small prefix assigned by the local administrator. The pool is small but the prefix is long. Should say long prefix assigned here. right, but long prefix seems counterintuitive as well. I had simply removed the small from the previous sentence, since the next sentence in the paragraph states that normally the IPv4 pool is small. The results is as follows: The IPv4 address pool is a set of IPv4 addresses, normally a prefix assigned by the local administrator. Since IPv4 address space is a scarce resource, the IPv4 address pool is small and typically not sufficient to establish permanent one-to-one mappings with IPv6 addresses. Section 3: This section introduces the concept of separate BIB and Session Tables for each of the three protocols. However, the definition of BIB in Section 2 makes direct use of the term session table. Does it need to be re-worded, and a separate definition for Session Table added? right, the definition of BIB in section 2 should read BIB table rather than session table i have changed that to t hangText=BIB:Binding Information Base. A table of bindings kept by a NAT64. Each NAT64 has a BIB for each translated protocol. An implementation compliant to this document would have a BIB for TCP, one for UDP and one for ICMP Queries. Additional BIBs would be added to support other protocols, such as SCTP./t Section 3.5.1: In the text describing handling an incoming IPv4 packet is the following: An IPv4 incoming packet, with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x) is processed as follows: The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 transport address matching (Y,y), (i.e., the IPv4 destination transport address in the incoming IPv4 packet). You seem to have switched letters here. (Y,y) is the SOURCE, not the destination, according to the first paragraph. I suggest sticking with the earlier lettering and assume the packet is sent to (T,t). The source of the packet could be (W,w) which may or may not equal (Z,z) depending on whether Address-Dependent filtering is in use. fixed and changed to the suggested notation Section 3.5.1: * The STE destination IPv6 transport address is set to (Z'(Y),y), y being the same port y than the destination IPv4 transport address SHOULD BE: * The STE destination IPv6 transport address is set to (Z'(Y),y), y being the same port y as the STE destination IPv4 transport address and the same as the source port contained in the received IPv4 packet Or, if you follow my suggestion above: * The STE destination IPv6 transport address is set to (Y'(W),w), w being the same port w as the STE destination IPv4 transport address and the same as the source port contained in the received IPv4 packet done Section 3.5.2.2 (two places): + The STE destination IPv6 transport address contains the port y (i.e. the same port than the destination IPv4 transport address) and the IPv6 representation of Y (i.e. the IPv4 address of the destination IPv4 transport address), generated using the algorithm described in Section 3.5.4. SHOULD BE: + The STE destination IPv6 transport address contains the port y (i.e. the same port as the STE destination IPv4 transport address and the same as the source port contained in the V4 SYN) and the IPv6 representation of Y (i.e. the IPv4 address of the destination IPv4 transport address), generated using the algorithm described in Section 3.5.4. changed In state V4 SYN RCV, when a V6 SYN arrives, should the stored V4 SYN be translated and sent on to the IPv6 network? This would seem to match the behavior in the V6 SYN RCV state. This was discussed in the WG and decided to discard the initial V4 SYN. This is so, because all this incoming v4 SYN processing is aimed to support only simultaneous opens, so, there is no need for the received to actually receive the v4 SYN and it would require
[Gen-art] Gen-ART LC Review of draft-ietf-netmod-yang-usage-07
Document: draft-ietf-netmod-yang-usage-07 Reviewer: Enrico Marocco Review Date: July 9, 2010 IETF LC End Date: July 8, 2010 Note: This review comes one day after the LC End Date, my bad. I'm sending it anyways, hoping it may be useful in the reminder of the publishing process. Feel free to ignore my late comments. Summary: This draft is on the right track but has open issues, described in the review. Major Issues: None. Minor Issues: Some guidelines in the document point to documents on the web that cannot be assumed to stay stable for as long as the RFC. My advice is to replace them with more stable references, or with new text in the document itself. In particular: S. 3. General Documentation Guidelines: replace the URL pointing to rfc-editor.org with references to RFC 2223. The first paragraph could be rewritten as: OLD: YANG data model modules under review are likely to be contained in Internet-Drafts. All guidelines for Internet-Draft authors MUST be followed. These guidelines are available online at: http://www.rfc-editor.org/rfc-editor/instructions2authors.txt NEW: YANG data model modules under review are likely to be contained in Internet-Drafts, formatted according to RFC 2223 [ref to the RFC] and its successors. S. 3.4. Security Considerations Section, first paragraph: is there really a need to define such a template in an external document (that most likely won't be reachable in a few years at the given URL)? Why not simply putting the whole template ( 2pg) in this document? [Note that the same document is also referenced in the draft's Security Considerations section.] Nits: Abstract: expand NETCONF (as per http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) and provide a few words about YANG for the casual reader. S. 3.3. Definitions Section, first para: define YIN. S. 3.4. Security Considerations Section, third bullet point: s/'rpc' statements/YANG 'rpc' statements/ S. 3.5.1. Documents that Create a New Name Space, second para: here citing I-D.ietf-netmod-yang after The YANG specification may help the reader. S. 4.1 Module Naming Conventions, third para: as I understand, an IANA registry is going to guarantee name uniqueness. Why not mentioning it here (other than in S. 4.7)? S. 4.4. Conditional Statements, third para: s/indicate the/indicate that the/ S. 4.5. XPath Usage, fourth para: quote the node properties provided as an example. Before that point names/variables are quoted. S. 4.5. XPath Usage, seventh para: quotes in the example again. S. 4.7. Module Header, Meta, and Revision Statements, second para: s/documented/document/ S. 4.10. Data Types: quote identityref, int32, enum and bit. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 8 July 2010
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-100708-lc.html *** Please note that some of these are due very soon (e.g., today) and some of them are already on the telechat agenda - I've indicated such in those assignments *** The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Assignments for July 15, 2010 Telechat
Hi all, Here's the link to the summary of assignments for the July 15th, 2010 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-100715.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://wiki.tools.ietf.org/area/gen/trac/wiki/ Mary. --- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 15 July 2010 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review: draft-ietf-tls-rfc4366-bis-09.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tls-rfc4366-bis-09.txt Transport Layer Security (TLS) Extensions: Extension Definitions Reviewer: Joel M. Halpern Review Date: 9-July-2010 IETF LC End Date: 2010-07-23 IESG Telechat date: N/A Summary: This document is ready for publication as a Proposed Standard. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
