RE: Gen-ART LC review of draft-ietf-repute-media-type-10
Thanks, Murray. The updates look good to me. -Peter From: Murray S. Kucherawy [mailto:superu...@gmail.com] Sent: Saturday, September 07, 2013 12:56 AM To: Peter Yee Cc: draft-ietf-repute-media-type@tools.ietf.org; General Area Review Team; ietf Subject: Re: Gen-ART LC review of draft-ietf-repute-media-type-10 Hi Peter, thanks for your review. Comments inline. On Thu, Aug 29, 2013 at 11:21 PM, Peter Yee pe...@akayla.com wrote: 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-repute-media-type-10 Reviewer: Peter Yee Review Date: August-27-2013 IETF LC End Date: August-29-2013 IESG Telechat date: September-12-2013 Summary: This draft is on the right track but has open issues, described in the review. [Ready with minor issues.] This draft directs IANA to register an application/reputon+json media type. It also defines a new IANA registry for reputation application-specific uses of that media type. Major issues: Minor issues: Authenticity and confidence ratings seem to be used interchangeably in the document. Authenticity is never defined, but it appears that it may previously have been used in place of confidence. The example spanning pages 9 and 10 notes a confidence of 95% but uses that for the (undefined in the document) authenticity value instead of the confidence value. Either define authenticity (which is absent in Section 3.1) or switch to confidence. This is actually a mistake. Earlier versions had something called rater-authenticity and did define it, but that component of a reputon has since been removed in favour of normal-rating. There are still some vestiges of the old text in there, which is causing this confusion. I'll clean it up. Section 3.1, definition of rater: the wording of this definition could be interpreted to mean either the party that is returning the rating information in response to the query but which is not necessarily the party creating the rating, or it could mean the party that created the rating. This may go back to the muddled concept of authenticity (which seems to be used to mean how much an unspecified someone believes that the rating originated with the named rater) vs. confidence (how confident the rater is in the rating). This definition should be cleared up to remove the ambiguity that floats throughout the document. Changing it to The identity of the entity aggregating, computing, and providing the reputation information, typically expressed as a DNS domain name. I can't think of a case where the party receiving the query is not also at least within the same ADMD as the party doing the computation, so this seems like the right definition to me. Nits: [...] All fixed. The auth-value one was old, as described above. Thanks! -MSK
Gen-ART Telechat review of draft-ietf-repute-media-type-12
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: draft-ietf-repute-media-type-12 Reviewer: Peter Yee Review Date: September-7-2013 IETF LC End Date: August-29-2013 IESG Telechat date: September-12-2013 Summary: This draft is ready for publication as a Standards Track RFC. [Ready.] This draft directs IANA to register an application/reputon+json media type. It also defines a new IANA registry for reputation application-specific uses of that media type. -Peter Yee
Gen-ART LC review of draft-ietf-repute-media-type-10
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-repute-media-type-10 Reviewer: Peter Yee Review Date: August-27-2013 IETF LC End Date: August-29-2013 IESG Telechat date: September-12-2013 Summary: This draft is on the right track but has open issues, described in the review. [Ready with minor issues.] This draft directs IANA to register an application/reputon+json media type. It also defines a new IANA registry for reputation application-specific uses of that media type. Major issues: Minor issues: Authenticity and confidence ratings seem to be used interchangeably in the document. Authenticity is never defined, but it appears that it may previously have been used in place of confidence. The example spanning pages 9 and 10 notes a confidence of 95% but uses that for the (undefined in the document) authenticity value instead of the confidence value. Either define authenticity (which is absent in Section 3.1) or switch to confidence. Section 3.1, definition of rater: the wording of this definition could be interpreted to mean either the party that is returning the rating information in response to the query but which is not necessarily the party creating the rating, or it could mean the party that created the rating. This may go back to the muddled concept of authenticity (which seems to be used to mean how much an unspecified someone believes that the rating originated with the named rater) vs. confidence (how confident the rater is in the rating). This definition should be cleared up to remove the ambiguity that floats throughout the document. Nits: Page 3, Section 3, 1st paragraph, 1st sentence: change representaton to representation. Change Javascript to JavaScript. Page 3, Section 3, 1st paragraph, 3rd sentence: delete the 3rd occurrence of context. Page 5, Section 4, 2nd paragraph, 2nd sentence: after given is there a missing application or query? Page 6, 1st paragraph, 1st sentence: change specificaiton to specification. Page 7, definition of auth-value: What is this?? Page 7, definition of ext-value, 1st comment: I think specific syntax is specified in specific application lacks specificity. ;-) Page 8, Section 6.2, 1st sentence after 1st example: who is we, Kemo Sabe? This seems to imply a rater who is rating the rater. There's also the aforementioned issue of what authenticity means vs. confidence. Page 9, 2nd paragraph after the example: change an to a. Page 9, 3rd paragraph after the example, 1st sentence: change idenfities to identifies. -Peter Yee
Gen-ART Telechat review of draft-jabley-dnsext-eui48-eui64-rrtypes-05
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: draft-jabley-dnsext-eui48-eui64-rrtypes-05 Reviewer: Peter Yee Review Date: July-07-2013 IETF LC End Date: July-17-2013 IESG Telechat date: August-15-2013 Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. [Ready with nits] This review is the same as the IETF LC review of this draft, which remain unchanged for the telechat. This draft defines DNS Resources Record Types for encoding IEEE 802 EUI-48 and EUI-64 addresses. Potential privacy issues with this scheme have been soundly beaten to death with extreme prejudice. Major issues: Minor issues: Nits: Page 1, Abstract, 1st paragraph: After e.g., append a comma and delete an extraneous space before Ethernet. Page 3, Introduction, 1st paragraph, 2nd sentence: change This to These and change specification defines to specifications define. Page 3, Introduction, 2nd paragraph: append a comma after e.g.. -Peter Yee
Gen-ART review of draft-ietf-geopriv-res-gw-lis-discovery-05
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 Document: draft-ietf-geopriv-res-gw-lis-discovery-05 Reviewer: Peter Yee Review Date: Jul-31-2013 IETF LC End Date: Jul-31-2013 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] The draft describes a means by which Devices behind a residential gateway may discover the correct Location Information Server on the access network providing Internet access to residential gateway. The Device may thereby gain access to certain location-based services. Major issues: None Minor issues: None Nits: Section 1, 1st paragraph, 2nd sentence: should data be appended after location? The wording is otherwise odd. Page 7, 3rd paragraph: change which to that. Page 9, section 4.2, 2nd paragraph, 1st sentence: I'll admit my ignorance of the finer points of the DNS and inquire what this sentence is supposed to mean. To what are the additional domain names added and how does this allow a DNS record to cover a larger set of addresses? Perhaps it's just the wording or my lack of knowledge, but I didn't follow this point fully. Page 9, section 4.2, 2nd bullet item: change sucessively to successively. Page 11, section 4.6, 1st paragraph, 4th sentence: insert a before STUN server or change server to servers depending on how many need to be configured. Page 12, 1st sentence: delete a. Page 12, 1st sentence: What about /56 for IPv6? Page 14, 3rd paragraph, 2nd sentence: delete a before IP addresses or change addresses to address depending on how many false addresses you mean. Page 14, 6th paragraph, last sentence: Are there any concrete suggestions on who a device might determine accuracy?
RE: Gen-ART Telechat review of draft-ietf-appsawg-rfc5451bis-09
Murray, Quick response! My replies are found below. Thanks. -Peter From: Murray S. Kucherawy [mailto:superu...@gmail.com] Sent: Monday, July 08, 2013 12:13 AM To: Peter Yee Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org; General Area Review Team; ietf Subject: Re: Gen-ART Telechat review of draft-ietf-appsawg-rfc5451bis-09 Hi Peter, thanks for the review. Comments inline: On Sun, Jul 7, 2013 at 10:38 PM, Peter Yee pe...@akayla.com wrote: Page 5, 2nd paragraph after bullet item, 1st sentence: change pre-standards DomainKeys defined to pre-standard DomainKeys-defined. This doesn't seem to work. The sentence is basically SPF defined X and DomainKeys defined Y. defined is a verb, not an adjective, so I don't think the hyphen is appropriate. Hmm. Yup, I misread that. Just ignore the hyphen part of the comment. Page 20, 5th full paragraph, 3rd sentence: regarding whether the field can be trusted: why would the MUA check the field in any other location than prior to the top-most trace field? If the location is the source of trustedness, then the MUA shouldn't be checking it anywhere else, right? Page 32, section 8.6, 3rd sentence: regarding keeping the list current, how about using a new RRType in the DNS? That's certainly one option to solve that problem. However, I'd prefer not to suggest new mechanisms that haven't been deployed yet. Fair enough. I'll post the rest in a -10 revision after the telechat, or if directed to do so sooner. Thanks again, -MSK
Gen-ART LC review of draft-jabley-dnsext-eui48-eui64-rrtypes-05
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-jabley-dnsext-eui48-eui64-rrtypes-05 Reviewer: Peter Yee Review Date: July-07-2013 IETF LC End Date: July-17-2013 IESG Telechat date: August-15-2013 Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. [Ready with nits] This draft defines DNS Resources Record Types for encoding IEEE 802 EUI-48 and EUI-64 addresses. Potential privacy issues with this scheme have been soundly beaten to death with extreme prejudice. Major issues: Minor issues: Nits: Page 1, Abstract, 1st paragraph: After e.g., append a comma and delete an extraneous space before Ethernet. Page 3, Introduction, 1st paragraph, 2nd sentence: change This to These and change specification defines to specifications define. Page 3, Introduction, 2nd paragraph: append a comma after e.g.. -Peter Yee
Gen-ART Telechat review of draft-ietf-appsawg-rfc5451bis-09
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-appsawg-rfc5451bis-09 Reviewer: Peter Yee Review Date: July-01-2013 IETF LC End Date: June-27-2013 IESG Telechat date: July-11-2013 Summary: This draft is basically ready for publication as a Standards Track RFC, but has nits that should be fixed before publication. [Ready with nits] This draft defines a message header for conveying message authentication outcomes from various, existing email authentication standards. The draft is well-written with numerous worked out examples. Major issues: Minor issues: Nits: Page 4, Introduction, 5th paragraph: append a comma after published. Page 5, 2nd paragraph after bullet item, 1st sentence: change pre-standards DomainKeys defined to pre-standard DomainKeys-defined. Page 6, 2nd paragraph, last sentence: change their data center to its data center. Page 6, section 1.3, 2nd sentence: change encapsualted to encapsulated. Page 7, section 1.5.2, 1st paragraph after bullet points, 2nd sentence: add commas after agents and authorization). Also change ensures to ensure. Page 14, section 2.5, 4th sentence: insert , but between document and intended. Page 17, Section 2.5.5: amend Authorhized to Authorized. Page 19, 2nd full paragraph, 2nd sentence: finite is probably not the best word to use here. Perhaps not unduly taxing to the DNS infrastructure would work better? Page 19, section 4, title: change A to a. Page 19, section 4, 1st paragraph, second sentence: change THe to The. Page 20, 2nd full paragraph, 1st sentence: append a comma after applied. Page 20, 5th full paragraph, 3rd sentence: insert placement between This and allows. Page 20, 5th full paragraph, 3rd sentence: regarding whether the field can be trusted: why would the MUA check the field in any other location than prior to the top-most trace field? If the location is the source of trustedness, then the MUA shouldn't be checking it anywhere else, right? Page 22, first full paragraph, 1st sentence: replace which with that. Page 22, 3rd full paragraph: this is an ambiguous reference. Maybe use these topics or these issues if you mean everything in the section? Page 23, 1st paragraph, last sentence: for clarity, consider inserting the header field originating from between removing and all. Page 23, 4th paragraph: as the MTA (implied to be an MTA within the ADMD) is not the end consumer of the information and the MUA might understand a later version of the header, shouldn't the decision to remove (or essentially ignore) the header be made by the MUA? Page 31, section 8.4, 2nd sentence: change need to needs. Page 32, section 8.6, 3rd sentence: regarding keeping the list current, how about using a new RRType in the DNS? Page 39, section C.4: the Received header would make it look like the message is going from example.net to example.com, but the To and From headers show the opposite to be the case. Page 39, section C.4: the same issue strikes the paragraph immediately following Example 4. The sending DNS name is what appears for the authserv-id, not the receiving DNS name. A simple swap of the To and From header values would rectify the situation. Page 43, 2nd paragraph, 2nd sentence: change that to whom. Page 44, item 1, 2nd sentence: delete the s in rejections. Page 44, item 3, 1st sentence: append a comma after header. Page 45, item 5, 3rd sentence: change vs to vs. and append a comma after intertia. -Peter Yee
Gen-ART LC review of draft-jabley-dnsext-eui48-eui64-rrtypes-04
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-jabley-dnsext-eui48-eui64-rrtypes-04 Reviewer: Peter Yee Review Date: June-09-2013 IETF LC End Date: June-17-2013 IESG Telechat date: Unknown Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. [Ready with nits] This draft defines DNS Resources Record Types for encoding IEEE 802 EUI-48 and EUI-64 addresses. General: I am aware of the debate on the IETF mailing list as to whether this draft could potentially harm user privacy. I'm of the opinion that this draft makes a useful specification of new DNS Resource Record Types. Misuse of this specification and many others could harm privacy, but that shouldn't necessarily dissuade us from publishing this draft. The security considerations cover the issues adequately. Major issues: Minor issues: Nits: Page 1, Abstract, 1st paragraph: After e.g., append a comma and delete an extraneous space before Ethernet. Page 3, Introduction, 1st paragraph, 2nd sentence: change This to These and change specification defines to specifications define. Page 3, Introduction, 2nd paragraph: append a comma after e.g.. Page 8, 1st paragraph, 1st sentence: change behaviour to behavior. Let's settle on the American variant of English for this draft. ;-) Page 10, 3rd paragraph: as others have pointed out, having the querier already know some other permanent identifier is security by obscurity and is not advised. -Peter Yee
RE: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
In Section 3.3.1.5: IEEE 802 standards, once approved, are published and made available for sale. This could be a cultural difference. RFC 6852 glosses over that (see Standards specifications are made accessible to all for implementation and deployment.) IEEE 802 standards are made more-or-less freely available (you have to agree to terms of use online) after a period of 6 months from publication. Details are here: http://standards.ieee.org/about/get/. -Peter
Gen-ART Telechat review of draft-ietf-netmod-ip-cfg-09
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. This draft has not been updated since my Last Call review, so the information below remains unchanged. Document: draft-ietf-netmod-ip-cfg-09 Reviewer: Peter Yee Review Date: May-03-2013 IETF LC End Date: May-03-2013 IESG Telechat date: May-16-2013 Summary: This draft is basically ready for publication as a Standards Track RFC, but has nits that should be fixed before publication. [Ready with nits] The abstract says it pretty well: This document defines a YANG data model for management of IP implementations. Major issues: Minor issues: Nits: Page 7, bottom: The code copyright date says 2012. Update it to 2013. Page 10, in leaf phys-address, the description has an incorrect spelling of neighbor. General: where a description of phys-address is given, in both cases it says The physical level address It might be more correct to state The link layer address... for most but not all cases. That's it. Everything appears consistent within the limits of my understanding of YANG. -Peter Yee
Gen-ART LC review of draft-ietf-netmod-ip-cfg-09
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-netmod-ip-cfg-09 Reviewer: Peter Yee Review Date: May-03-2013 IETF LC End Date: May-03-2013 IESG Telechat date: May-16-2013 Summary: This draft is basically ready for publication as a Standards Track RFC, but has nits that should be fixed before publication. [Ready with nits] The abstract says it pretty well: This document defines a YANG data model for management of IP implementations. Major issues: Minor issues: Nits: Page 7, bottom: The code copyright date says 2012. Update it to 2013. Page 10, in leaf phys-address, the description has an incorrect spelling of neighbor. General: where a description of phys-address is given, in both cases it says The physical level address It might be more correct to state The link layer address... for most but not all cases. That's it. Everything appears consistent within the limits of my understanding of YANG. -Peter Yee
RE: [Gen-art] Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Grrr, typo in the subject line. That should be draft version -08, as correctly referenced below. Sigh. -Peter -Original Message- From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of Peter Yee Sent: Tuesday, April 23, 2013 10:57 PM To: draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: [Gen-art] Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 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: draft-ietf-pcp-upnp-igd-interworking-08 Reviewer: Peter Yee Review Date: Apr-23-2013 IETF LC End Date: Apr-08-2013 IESG Telechat date: Apr-25-2013 Summary: This draft is ready for publication as a Standards Track RFC. [Ready] This is a well-written draft describing how Universal Plug-and-Play Internet Gateway Devices interwork with NAT devices that use the Port Control Protocol. All of my previous review comments on the draft have been addressed. -Peter ___ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
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: draft-ietf-pcp-upnp-igd-interworking-08 Reviewer: Peter Yee Review Date: Apr-23-2013 IETF LC End Date: Apr-08-2013 IESG Telechat date: Apr-25-2013 Summary: This draft is ready for publication as a Standards Track RFC. [Ready] This is a well-written draft describing how Universal Plug-and-Play Internet Gateway Devices interwork with NAT devices that use the Port Control Protocol. All of my previous review comments on the draft have been addressed. -Peter
RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Med, That looks great. Thanks for accommodating my concern. Kind regards, -Peter -Original Message- From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] Sent: Wednesday, April 10, 2013 12:49 AM To: Peter Yee; draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Dear Peter, I changed the text as follows: OLD: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response. If a short lifetime error is returned, the IGD-PCP IWF MAY re-send the same request to the PCP Server after 30 seconds. If a PCP error response is received, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. NEW: If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response: 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend the same request to the PCP Server after 30 seconds without relaying the error to the UPnP Control Point. The IGD-PCP IWF MAY repeat this process until a positive answer is received or some maximum retry limit is reached. When the maximum retry limit is reached, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. 2. If a long lifetime error is returned, the IGD-PCP IWF relays a negative message to the UPnP Control Point with ConflictInMappingEntry as the error code. Better? Cheers, Med -Message d'origine- De : Peter Yee [mailto:pe...@akayla.com] Envoyé : mardi 9 avril 2013 20:58 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-pcp-upnp-igd- interworking@tools.ietf.org Cc : gen-...@ietf.org; ietf@ietf.org Objet : RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07 Med, Thanks for the swift response to my review. See my one reply inline. Kind regards, -Peter Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. [Med] The basic behavior is to relay the received error to the UPnP CP. For the short-lifetime errors, the IWF may decide to resend the request and not relay those errors immediately to the UPnP CP. The number of repeats is not specified here as it can be implementation-specific. Your explanation is fine. I just found the wording If a PCP error response is received to sound ambiguously as if the short-lifetime errors were not a subset of PCP errors.
Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
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-pcp-upnp-igd-interworking-07 Reviewer: Peter Yee Review Date: Apr-08-2013 IETF LC End Date: Apr-08-2013 IESG Telechat date: Unknown Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues] This is a well-written draft describing how Universal Plug-and-Play Internet Gateway Devices interwork with NAT devices that use the Port Control Protocol. My review is mostly nits with otherwise minor issues. I have no problems with the general concept and enjoyed reading a clearly articulated concept. Major Issues: None. Minor Issues: Section 4.1: is the mapping of the state variables between the UPnP IGD function and the PCP Client function really straightforward such that it does not need further description? I'm asking if an implementor would naturally gravitate to the correct use of the mapping without further instructions. Similar questions arise for Sections 4.2 and 4.3, although I believe those are more straightforward mappings. Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. Nits: General: replace re-send with resend. Page 3, 1st paragraph, 2nd sentence: insert a before each occurrence of UPnP. Page 4, section 3, 4th bullet: consider changing in to on or over. Page 4, 1st paragraph after the bullet items: bracket for instance with commas. Page 5, Figure 3: perhaps the LAN Side label could move a bit to the left to give it better delineation from the External Side label? Page 5, 1st paragraph after Figure 4, 2nd sentence: add a comma after [I-D.ietf-pcp-base]. Page 5, 2nd paragraph after Figure 4: change can not to cannot. Page 9, section 5, 3rd paragraph: insert the same way or the same before as any PCP Client. Page 9, section 5.1, 2nd paragraph: insert whether before it should. Page 9, section 5.1, 3rd paragraph: insert the before requesting UPnP Control Point. Page 10, Section 5.3, 2nd paragraph, 1st sentence: consider changing retrieve to extract. Page 11, 1st paragraph after bullet items, 2nd sentence: change to to than. Page 11, Section 5.6: swap the order of AddPortMapping() and AddAnyPortMapping() to match the order of the subsequent subsections. Page 11, Section 5.6.1, 2nd paragraph, 2nd sentence: change 30s to 30 seconds. Page 13, 1st paragraph, 4th sentence: change re-issue to issue; change new requested to different requested. Page 14, last paragraph: delete the comma after 4 times). Page 15, Section 5.7, 1st paragraph: append a comma after GetSpecificPortMappingEntry(). Page 15, Section 5.7, 3rd paragraph, 3rd sentence: replace 60s with 60 seconds. Page 15, Section 5.7, 3rd paragraph, last sentence: insert the before error code; change enquried to queried. Page 15, Section 5.8, 1st paragraph: insert , respectively before the period. Page 15, Section 5.8, 2nd paragraph, 2nd sentence: insert the before '606 Action Not'. Page 16, last paragraph, 2nd sentence: insert the before'731 PortMappingNotFound'. Page 19, 1st continuation paragraph, 1st sentence fragment: change of to in. Page 19, 1st continuation paragraph, 1st full sentence: consider swapping the positions of renew and periodically for readability. Page 19, Section 5.10, 1st paragraph, 2nd sentence: I prefer In particular to Particularly here. Page 19, Section 5.10, 3rd paragraph, 3rd sentence: replace signalled with signaled.
RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
Med, Thanks for the swift response to my review. See my one reply inline. Kind regards, -Peter Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error other than a short-lifetime error, or in the case of a failed resend, any PCP error at all. The wording makes it seem like the short-lifetime errors are somehow not PCP errors and is therefore confusing. It also doesn't explicitly deal with how many repeats should be done on a resend. [Med] The basic behavior is to relay the received error to the UPnP CP. For the short-lifetime errors, the IWF may decide to resend the request and not relay those errors immediately to the UPnP CP. The number of repeats is not specified here as it can be implementation-specific. Your explanation is fine. I just found the wording If a PCP error response is received to sound ambiguously as if the short-lifetime errors were not a subset of PCP errors.
Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06
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: draft-ietf-intarea-nat-reveal-analysis-06 Reviewer: Peter Yee Review Date: Apr-5-2013 IETF LC End Date: Mar-8-2013 IESG Telechat date: Apr-11-2013 This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits] It addresses most of the issues raised in my review of the -05 version. Two items from that review that I'm revisiting are noted below with text from the original review and responses from one of the authors (Med). We agreed that those two revisited items could be addressed in a subsequent revision; they are just recorded here for ease of reference. Major issues: Minor issues: Nits: [Old] Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Med: The point is: when several layers are used to inject a host_id, the device should check the same subset of information is revealed. For instance, there should not be conflict, etc. Then perhaps you could reword so that should reveal subsets of the same information becomes should reveal the same subsets of information at each layer? Section 4.9.2, 4th bullet item, 2nd sentence: Delete heavy and unless you want to explain what heavy means. Med: Establishing agreements with the owner of the address sharing function and owners of servers is heavy. This is already mentioned in the text. Perhaps you could replace heavy with burdensome. [New] In the references, there seem to be an excess of commas in a couple of places. Look for the string , , (comma space comma) and you'll see what I mean. The document titles start with an extra comma and end with one. Also in the references, for RFC 1413, put a space between the M. and the C. in Mike St. Johns' initials.
Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
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 Document: draft-ietf-intarea-nat-reveal-analysis-05 Reviewer: Peter Yee Review Date: Mar-08-2013 IETF LC End Date: Mar-08-2013 IESG Telechat date: TBD Summary: This draft is on the right track but has open issues, described in the review. [Ready with issues.] This draft catalogs and analyzes various means of supplying a host identifier to a remote server when Carrier Grade NAT or similar host obscuring technology is in use. General: There were sentences in the draft that I could not parse even in the context of surrounding text. That's primarily why I'm marking this draft as Ready with issues. These sentences are supplied below. Mostly, the document has a fair number of nits. The general concept is fine. General: hyphenate uses of address sharing when it used as an adjective. For example, address-sharing device. General: expand acronyms on first use except if they are really well known in our community (e.g., TCP/IP) or where they appear in the abstract. Examples of acronyms in need of expansion are HIP, XFF, . General: You will probably want to resolve Internet Draft references to something more permanent. General: The term broken should be replaced with something more specific or useful. I've made some suggestions below. Section 1, 2nd paragraph, last sentence: delete an before information. Section 1, 3rd paragraph: change are to include. Section 1, 3rd paragraph: change customers unsatisfaction to and customers' dissatisfaction. Section 2, 1st paragraph, 2nd sentence: delete an before extra. Change than to beyond. Section 2, 1st paragraph, 3rd sentence: replace this sentence with We call this information the HOST_ID. Section 2, 2nd paragraph: add a serial comma after subscriber. Serial comma use in the draft was inconsistent. Section 2, 3rd paragraph, 3rd sentence: I'm not sure why the HOST_ID and public IP address would be relatively unique. Assuming that HOST_IDs are unique amongst the hosts hidden behind the public IP address and the public IP address is unique, I would have thought that the combination was globally unique. My confusion may arise from the 4th sentence which is incomplete. Perhaps those two sentences could be rewritten for clarity. Section 2, 4th paragraph, 1st sentence: change put to conveyed. Section 2, 4th paragraph, 2nd sentence: change put to conveyed. Section 3, 2nd paragraph, 1st sentence: considering using identifiability instead of uniqueness. Section 3, 2nd paragraph, 2nd sentence: replace which with what. Section 3,1, 4th paragraph: add a comma after re-write. Change re-write to rewrite. Section 3.1, 5th paragraph: I don't quite follow what's being said here. Is the point that the address-sharing function should reveal the same HOST_ID for any given host regardless of what layer or mechanism that HOST_ID is being conveyed across? How does this relate to interference between HOST_IDs? Section 4.1.1, 1st paragraph, 1st sentence: delete an before information. Section 4.1.1, 1st paragraph, 3rd sentence: insert , there are after hence. Section 4.1.1, 4th paragraph, consider replacing with: Address-sharing devices using this solution would be required to indicate that out of band, possibly using a special DNS record. Section 4.1.2, 3rd paragraph, 2nd sentence: add a comma after scenario. Change broken to ill-advised. Section 4.2.1, 1st paragraph, 2nd sentence: add A at the beginning of the sentence. Section 4.2.1, 1st paragraph, 4th sentence: rewrite as This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a GRE key, an IPv6 Flow Label, etc. Section 4.2.1, 2nd paragraph: insert an before IP. Section 4.2.2, 1st paragraph, 1st sentence: change for to to. Section 4.2.2, 1st paragraph, 2nd sentence: use of the term filter in this sentence is not clear. Do you mean that that routes and middleboxes remove the IP options? Or that they remove packets with IP options? Or that they take other actions based on the presence of IP options? Please clarify. Section 4.2.2, 2nd paragraph: replace As a with In. Define host-hint somewhere. Is it meant to be equivalent to HOST_ID? Section 4.3.1, 3rd sentence: change their to its both places in the sentence. Insert or before subscriber. Section 4.3.2, 2nd paragraph, 2nd sentence: insert a before HOST_ID Section 4.3.2, 2nd paragraph, 3rd sentence: change in host to on the host. Insert the before address, and add a comma after function. Section 4.3.2, 1st bullet item: this is the IETF. We don't need no stinkin' OSI! :-) Section 4.3.2, 1st bullet item, 2nd sentence: replace the sentence with Moreover, an updated version of [I-D.wing-nat-reveal-option] no longer allows conveyance of a full IP address as the HOST_ID is encoded in 16 bits. Section 4.3.2, 2nd bullet item, 1st sentence: delete the comma after limited
Gen-ART review of draft-ietf-roll-security-threats-00
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. (My apologies for submitting these a day late.) Document: draft-ietf-roll-security-threats-00 Reviewer: Peter Yee Review Date: Jan-22-2012 IETF LC End Date: Jan-21-2012 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document analyzes security threats for routing in a low-power and lossy networks. It discusses countermeasures and operational considerations for dealing with the threats in the design of ROLL protocols. Major issues: Minor issues: Nits/editorial comments: General: replace low power with low-power throughout the document to match usage in other ROLL RFCs General: replace a LLN with an LLN throughout the document. General: there are quite a few really long, dense sentences in this document. They make parsing and comprehension more difficult. I realize that's not something terribly concrete on which you can act. Section 1, 1st paragraph, 2nd sentence: insert a before user access interface or consider making interface plural. Section 2, definition of Node: place a comma after power. Section 3, 1st paragraph, 2nd sentence: since you're going to use CIA later in the document, perhaps you would like to include integrity in this sentence. Section 3.1, 1st paragraph, 3rd sentence: an adjective such as improper or unauthorized before access would be helpful. Section 3.3, 5th paragraph, last sentence: make damages singular. Section 4.1.1, second sentence: add a period after etc. Section 4.3.2, Figure 2: I'm not sure why Falsify as Good Link to Node_5 appears twice. Perhaps delete one? Section 4.3.4, 1st paragraph, 1st sentence: add a serial comma after memory. Section 5.1.4, 3rd paragraph, last sentence: add a serial comma after integrity. Section 5.1.4, 6th paragraph, 1st sentence: consider mentioning FIPS 140-2 not just for device hardening but for other tamper-resistance mechanisms and for correctness of cryptographic operations (including random number generation). Section 5.2.3, 2nd paragraph, 2nd sentence: consider changing explicit and implicit to explicitly and implicitly. If not, rewrite the sentence so it parses. Section 5.2.3, 3rd paragraph, 2nd sentence: replace shared key or public key based with a shared key- or public key-based. Section 5.2.4, 2nd sentence: add an s after need Section 5.2.5, 5th paragraph: You might also wish to consider an intrusion detection system (within the node and/or in conjunction with other nodes) as an alternative to external audit entity. The literature for MANETs has much to offer in this regard. The seminal paper is: Zhang, Y. Lee, W. (2000). Intrusion detection in wireless ad-hoc networks. Proceedings of the 6th International Conference on Mobile Computing and Networking (MobiCom 2000), 275-283. doi:10.1145/345910.345958 Also consider: Liu, Y., Comaniciu, C., Man, H. (2006). A Bayesian game approach for intrusion detection in wireless ad hoc networks. Proceedings of the 2006 Workshop on Game Theory for Communications and Networks (GAMENET06). doi:0.1145/1190195.1190198 Li, W., Parker, J., Joshi, A. (2012). Security through collaboration and trust in MANETs. Mobile Networks Applications, 17(3), 342-352. doi:10.1007/s11036-010-0243-9 Section 5.3, 1st sentence: Drop a before proper. Section 5.3.2, 1st paragraph, 1st sentence: replace battery or energy scavenging with batteries or energy scavenging. Section 5.3.2, 1st paragraph, 2nd sentence: replace battery with energy-constrained. Section 5.3.3, 2nd bullet item: add ing to select. Section 5.3.3, last paragraph, 2nd sentence: add a before method. Section 5.3.3, last paragraph, 2nd sentence: it's also suboptimal from a network utilization perspective. Section 6, 2nd paragraph, 3rd sentence: delete that before do not of. Section 6, last paragraph, last sentence: add a serial comma after integrity. Section 6.1., 1st paragraph after bullet items: change accordance of to accordance with. Section 6.2, 4th bullet item: add a comma after increments. Section 6.2, 1st paragraph after bullet items, 2nd sentence: add be before used. Section 6.2, 1st paragraph after bullet items, last sentence: insert counting between as and against. Section 6.4, 5th paragraph, 3rd sentence: add ly after separate. Section 6.4, 5th paragraph, 3rd sentence: remove the space in IETF- standard. Section 6.4, 5th paragraph, 4th sentence: change IKE to IKEv2. Section 6.4, 5th paragraph, 4th sentence: consider changing private to secret to avoid confusion between symmetric and asymmetric cryptograph concepts. Section 6.5.1, 3rd paragraph, 1st sentence: add ly after independent. Section 6.5.1, 8th paragraph, 2nd
RE: Gen-ART review of draft-ietf-6man-udpchecksums-06
Magnus, Looks good to me. My summary is now Ready for publication. Kind regards, -Peter -Original Message- From: Magnus Westerlund [mailto:magnus.westerl...@ericsson.com] Sent: Thursday, January 17, 2013 2:59 AM To: Peter Yee Cc: draft-ietf-6man-udpchecksums@tools.ietf.org; gen-...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-6man-udpchecksums-06 Hi Peter, Thanks for your detailed review. An updated version has just been submitted the includes fixes to your comments. Thanks Magnus On 2012-12-26 12:05, Peter Yee wrote: 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: draft-ietf-6man-udpchecksums-06 Reviewer: Peter Yee Review Date: Dec-25-2012 IETF LC End Date: Dec-25-2012 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides an update to 2460 to allow the use of zero checksum UDP packets over IPv6 in certain cases involving protocols tunneled inside of UDP packets. Nits: General: a comma after i.e. is preferred in American English. General: it is not necessary to hyphenate misdelivered or misdelivery. General: put quotes around Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums Abstract, first sentence: when - where Abstract, second sentence: protocol - protocols Section 1, second paragraph, first sentence: delete the comma after packet. Section 1, fourth paragraph, first sentence: move the comma in AMT, to after the reference. Section 1, fourth paragraph, last sentence: insert the after applicable in. Section 3, second sentence: delete the first occurrence of where. Consider revising the sentence for clarity. Section 4, second sentence: Section - Sections Section 4.1, it would be nice, but not necessary to have an enumeration of the corruption modes. Section 4.1, third bullet item, first sentence: a verb is missing here making the sentence difficult to parse. Section 4.1, third bullet item, first sentence: packets - packet Section 4.1, third bullet item, third sub-bullet: put commas around for example. Section 4.2, first bullet item, last sentence: this sentence is hard to understand; consider revising. (See next comment) Section 4.2, first bullet item, last sentence: an - a and are - is; also not general comment about misdelivered. Section 4.2, third bullet item, third sentence: effect - affect Section 4.2, first paragraph after bullet items, first sentence: delete this. Section 4.2, first paragraph after bullet items, third sentence: mis-delievery - misdelivery. Section 4.2, first paragraph after bullet items, third sentence: delete that. Section 4.3, first sentence: middlebox devices - middleboxes unless this a specific usage from I-D.ietf-6man-udpzero. Section 4.3, second sentence: needs - need Section 5, first paragraph, second sentence: insert in after node requirements. Section 5, first paragraph of replacement text, second sentence: delete usage for, replace some with certain, and replace second protocols with those. Section 5, last paragraph: delete first instance of the. Section 6, first bullet item, first sentence: corruptions - corruption Section 6, second bullet item, last sentence: change This to UDP-Lite. Section 8, first sentence: delete redundant required. -- Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Gen-ART review of draft-ietf-6man-udpchecksums-06
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: draft-ietf-6man-udpchecksums-06 Reviewer: Peter Yee Review Date: Dec-25-2012 IETF LC End Date: Dec-25-2012 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides an update to 2460 to allow the use of zero checksum UDP packets over IPv6 in certain cases involving protocols tunneled inside of UDP packets. Nits: General: a comma after i.e. is preferred in American English. General: it is not necessary to hyphenate misdelivered or misdelivery. General: put quotes around Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums Abstract, first sentence: when - where Abstract, second sentence: protocol - protocols Section 1, second paragraph, first sentence: delete the comma after packet. Section 1, fourth paragraph, first sentence: move the comma in AMT, to after the reference. Section 1, fourth paragraph, last sentence: insert the after applicable in. Section 3, second sentence: delete the first occurrence of where. Consider revising the sentence for clarity. Section 4, second sentence: Section - Sections Section 4.1, it would be nice, but not necessary to have an enumeration of the corruption modes. Section 4.1, third bullet item, first sentence: a verb is missing here making the sentence difficult to parse. Section 4.1, third bullet item, first sentence: packets - packet Section 4.1, third bullet item, third sub-bullet: put commas around for example. Section 4.2, first bullet item, last sentence: this sentence is hard to understand; consider revising. (See next comment) Section 4.2, first bullet item, last sentence: an - a and are - is; also not general comment about misdelivered. Section 4.2, third bullet item, third sentence: effect - affect Section 4.2, first paragraph after bullet items, first sentence: delete this. Section 4.2, first paragraph after bullet items, third sentence: mis-delievery - misdelivery. Section 4.2, first paragraph after bullet items, third sentence: delete that. Section 4.3, first sentence: middlebox devices - middleboxes unless this a specific usage from I-D.ietf-6man-udpzero. Section 4.3, second sentence: needs - need Section 5, first paragraph, second sentence: insert in after node requirements. Section 5, first paragraph of replacement text, second sentence: delete usage for, replace some with certain, and replace second protocols with those. Section 5, last paragraph: delete first instance of the. Section 6, first bullet item, first sentence: corruptions - corruption Section 6, second bullet item, last sentence: change This to UDP-Lite. Section 8, first sentence: delete redundant required.
Gen-ART review of draft-ietf-avt-rtp-evrc-nw-0
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: draft-ietf-avt-rtp-evrc-nw-09 Reviewer: Peter Yee Review Date: Dec-19-2012 IETF LC End Date: Dec-11-2012 IESG Telechat date: Dec-20-2012 Summary: This draft is ready for publication as a Standards Track RFC.
Gen-ART review of draft-ietf-avt-rtp-evrc-nw-08
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-avt-rtp-evrc-nw-08 Reviewer: Peter Yee Review Date: Dec-11-2012 IETF LC End Date: Dec-11-2012 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has a few nits that should be fixed before publication. [Ready with nits.] This Standards Track draft specifies RTP payload formats for use with the EVRC-NW. It contains IANA registration requests. Major issues: Minor issues: Nits/editorial comments: Section 1, 2nd sentence: decide whether you want to capitalize the packet format names (Header-Free, Interleaved/Bundled) and then them use consistently throughout the document. RFC 3558 uses upper case names mostly, but is not quite a paragon of consistency. Section 4, 3rd sentence: change zero bit to zero-bit. Section 4, table, 1st row: insert a space after Blank and adjust spacing to maintain alignment of the columns. Change 0 bit to 0 bits. Section 5, 2nd paragraph, 3rd sentence: change 8kHz to 8 kHz. Change 16kHz to 16 kHz. Section 6, 3rd numbered item, 2nd sentence: change identfication to identification. Section 7, 1st sentence: change ; to ,. Section 9.1.2: change Interoperability considertaions to Interoperability considerations. Section 9.1.3, mode-set-recv paragraph, 5th sentence: change narroband to narrowband. Section 9.1.3: change Interoperability considertaions to Interoperability considerations. Section 10, 1st paragraph, 2nd sentence: delete the comma after preference. Section 10, numbered list: I'm not sure why this is a numbered list since the preceding paragraph makes no direct link to it. Consider demoting the list items to individual paragraphs. Section 10, 1st numbered item, 1st sentence: consider rewriting inform the capability of as advertise the capability for or inform the capability for. Section 10, 2nd numbered item, 1st sentence: rewrite inform the as indicate a. Section 11, 2nd paragraph, 4th sentence: change potentially-high to potentially high Section 11, 2nd paragraph, last sentence: change is used to be used. Section 14, 2nd bullet item, 2nd sentence: capitalize may and should. Section 14, 3rd bullet item: change receive only to receive-only. I like using the serial comma (the one before and in a list of 3 of more items) for clarity and to reduce confusion, but did not submit the list of missing commas for this document -- there are a few. Let me know if you care.
Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-14
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: draft-ietf-nfsv4-federated-fs-protocol-14 Reviewer: Peter Yee Review Date: Nov-29-2012 IETF LC End Date: Oct-22-2012 IESG Telechat date: Nov-29-2012 Summary: This draft is basically ready for publication, but has a nit that should be fixed before publication. [Ready with nits.] All other corrections from the -13 review were accepted and the other changes in the current version appear reasonable. Major issues: Minor issues: Nits/editorial comments: Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket Section 2.8.1 in (see and ) for readability. [This is my same suggestion from the previous review. I won't mention it again, I promise. :-) ]
Re: Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13
Chuck, I'll cheerfully settle for the status quo. Please ignore that comment. Thanks. -Peter On Oct 22, 2012, at 4:10 PM, Chuck Lever chuck.le...@oracle.com wrote: On Oct 21, 2012, at 11:35 PM, Peter Yee pe...@akayla.com wrote: Chuck, Ranges include the 0,255 that appears commonly in the document in attribute definitions along with one case of -2147483648,2147483647. Hi Peter- Upon further review, I see the document uses interval notation when defining ranges of allowed values in attributes. The use of square brackets denotes inclusivity. If you feel readers need more, or our use of this notation is inconsistent, I'm happy to add clarification. Kind regards, -Peter On 10/21/12 3:27 PM, Chuck Lever chuck.le...@oracle.com wrote: On Oct 21, 2012, at 5:39 PM, Peter Yee pe...@akayla.com wrote: 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 Document: draft-ietf-nfsv4-federated-fs-protocol-13 Reviewer: Peter Yee Review Date: Oct-19-2012 IETF LC End Date: Oct-22-2012 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This Standards Track document describes a protocol for maintaining a Namespace Database for use with federated filesystem protocols. The document is well-written with good examples and little need to jump back and forth in the text to understand it. General: Are ranges (in attribute values) inclusive or exclusive? They appear to be inclusive, but it might be worth saying that somewhere, if only once. Can you give me an example of a range that might need clarification? I will address these comments and co-ordinate draft updates with our WG editor, Tom Haynes. Thanks for your review. Section 2.7, NsdbName definition: expand NSDB to Namespace Database as this is the first use of the term. Section 2.8.1, 2nd sentence: extention - extension Section 2.8.3, 2nd paragraph, last sentence: in addition to checking for added FSL records, shouldn't the fileserver also be checking for deleted or migrated FSLs? And why would the fileserver do this at the expiration of the FSN TTL instead of waiting for the next access to the that FSN? Otherwise the fileserver could be generating unnecessary traffic, although there is a tradeoff to be made vs. performance. Section 2.8.3, 3rd paragraph after bullet items, 1st sentence: which - that. (Yeah, I know, grammar police.) Section 2.9, 3rd paragraph, 2nd sentence: admininistrative - administrative Section 2.12, 2nd paragraph, last sentence: expand NCE (NSDB Container Entry) as this is the first use of the term. Section 3.2, item #5: fs_location - fs_locations Section 4.1, 1st paragraph, 3rd sentence: probably worth expanding DSE to DSA-specific entry here. Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket Section 2.8.1 in (see and ) for readability. Section 4.2.2: LDAP Objects - LDAP Object Classes seems appropriate. Section 4.2.2.1, 2nd and 3rd sentences: replace fedfsFsn with fedfsNsdbContainerInfo Section 4.2.2.2, 5th paragraph: how is the prohibition on referencing other attributes in the fedfsFsn object class supposed to work if this document is the defining document for that object class? Section 5.1.3.1, 1st paragraph after LDIF definition: a port number of 2049 is given. Since this is already the default value, why not use a different value? Otherwise, there would be no practical need to include that port number in the FSL creation request. Section 5.1.3.1, 1st paragraph after LDIF definition: up to date - up-to-date Section 5.1.3.2, 2nd paragraph: a - an Section 5.1.3.2, table entry for fedfsNfsVarSub: substituion - substitution Section 5.1.4, 1st paragraph, 1st sentence: a Fileset location - an FSL Section 7.3, 2nd paragraph, Specification value: presumably this will be changed to the RFC number when issued? Section 8, 1st paragraph (definition of Administrator): an - a Section 8, 3rd paragraph (definition of Client): filesystem access - file-access for consistency of usage with the rest of the document. Section 8, 5th paragraph (definition of Fileserver): rather than discussing a filesystem, should this be one or more filesystems? Or is a fileserver limited to exporting one filesystem? Section 8, 8th paragraph (definition of Filesystem Access Protocol): following up on the 3rd paragraph, should this be File-access Protocol for consistency? Section 8, 9th paragraph (definition of FSL), 2nd sentence: fs_location - fs_locations. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com default[4].xml -- Chuck Lever chuck[dot]lever[at]oracle[dot]com
Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13
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 Document: draft-ietf-nfsv4-federated-fs-protocol-13 Reviewer: Peter Yee Review Date: Oct-19-2012 IETF LC End Date: Oct-22-2012 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This Standards Track document describes a protocol for maintaining a Namespace Database for use with federated filesystem protocols. The document is well-written with good examples and little need to jump back and forth in the text to understand it. General: Are ranges (in attribute values) inclusive or exclusive? They appear to be inclusive, but it might be worth saying that somewhere, if only once. Section 2.7, NsdbName definition: expand NSDB to Namespace Database as this is the first use of the term. Section 2.8.1, 2nd sentence: extention - extension Section 2.8.3, 2nd paragraph, last sentence: in addition to checking for added FSL records, shouldn't the fileserver also be checking for deleted or migrated FSLs? And why would the fileserver do this at the expiration of the FSN TTL instead of waiting for the next access to the that FSN? Otherwise the fileserver could be generating unnecessary traffic, although there is a tradeoff to be made vs. performance. Section 2.8.3, 3rd paragraph after bullet items, 1st sentence: which - that. (Yeah, I know, grammar police.) Section 2.9, 3rd paragraph, 2nd sentence: admininistrative - administrative Section 2.12, 2nd paragraph, last sentence: expand NCE (NSDB Container Entry) as this is the first use of the term. Section 3.2, item #5: fs_location - fs_locations Section 4.1, 1st paragraph, 3rd sentence: probably worth expanding DSE to DSA-specific entry here. Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket Section 2.8.1 in (see and ) for readability. Section 4.2.2: LDAP Objects - LDAP Object Classes seems appropriate. Section 4.2.2.1, 2nd and 3rd sentences: replace fedfsFsn with fedfsNsdbContainerInfo Section 4.2.2.2, 5th paragraph: how is the prohibition on referencing other attributes in the fedfsFsn object class supposed to work if this document is the defining document for that object class? Section 5.1.3.1, 1st paragraph after LDIF definition: a port number of 2049 is given. Since this is already the default value, why not use a different value? Otherwise, there would be no practical need to include that port number in the FSL creation request. Section 5.1.3.1, 1st paragraph after LDIF definition: up to date - up-to-date Section 5.1.3.2, 2nd paragraph: a - an Section 5.1.3.2, table entry for fedfsNfsVarSub: substituion - substitution Section 5.1.4, 1st paragraph, 1st sentence: a Fileset location - an FSL Section 7.3, 2nd paragraph, Specification value: presumably this will be changed to the RFC number when issued? Section 8, 1st paragraph (definition of Administrator): an - a Section 8, 3rd paragraph (definition of Client): filesystem access - file-access for consistency of usage with the rest of the document. Section 8, 5th paragraph (definition of Fileserver): rather than discussing a filesystem, should this be one or more filesystems? Or is a fileserver limited to exporting one filesystem? Section 8, 8th paragraph (definition of Filesystem Access Protocol): following up on the 3rd paragraph, should this be File-access Protocol for consistency? Section 8, 9th paragraph (definition of FSL), 2nd sentence: fs_location - fs_locations.
Re: Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13
Chuck, Ranges include the 0,255 that appears commonly in the document in attribute definitions along with one case of -2147483648,2147483647. Kind regards, -Peter On 10/21/12 3:27 PM, Chuck Lever chuck.le...@oracle.com wrote: On Oct 21, 2012, at 5:39 PM, Peter Yee pe...@akayla.com wrote: 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 Document: draft-ietf-nfsv4-federated-fs-protocol-13 Reviewer: Peter Yee Review Date: Oct-19-2012 IETF LC End Date: Oct-22-2012 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This Standards Track document describes a protocol for maintaining a Namespace Database for use with federated filesystem protocols. The document is well-written with good examples and little need to jump back and forth in the text to understand it. General: Are ranges (in attribute values) inclusive or exclusive? They appear to be inclusive, but it might be worth saying that somewhere, if only once. Can you give me an example of a range that might need clarification? I will address these comments and co-ordinate draft updates with our WG editor, Tom Haynes. Thanks for your review. Section 2.7, NsdbName definition: expand NSDB to Namespace Database as this is the first use of the term. Section 2.8.1, 2nd sentence: extention - extension Section 2.8.3, 2nd paragraph, last sentence: in addition to checking for added FSL records, shouldn't the fileserver also be checking for deleted or migrated FSLs? And why would the fileserver do this at the expiration of the FSN TTL instead of waiting for the next access to the that FSN? Otherwise the fileserver could be generating unnecessary traffic, although there is a tradeoff to be made vs. performance. Section 2.8.3, 3rd paragraph after bullet items, 1st sentence: which - that. (Yeah, I know, grammar police.) Section 2.9, 3rd paragraph, 2nd sentence: admininistrative - administrative Section 2.12, 2nd paragraph, last sentence: expand NCE (NSDB Container Entry) as this is the first use of the term. Section 3.2, item #5: fs_location - fs_locations Section 4.1, 1st paragraph, 3rd sentence: probably worth expanding DSE to DSA-specific entry here. Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket Section 2.8.1 in (see and ) for readability. Section 4.2.2: LDAP Objects - LDAP Object Classes seems appropriate. Section 4.2.2.1, 2nd and 3rd sentences: replace fedfsFsn with fedfsNsdbContainerInfo Section 4.2.2.2, 5th paragraph: how is the prohibition on referencing other attributes in the fedfsFsn object class supposed to work if this document is the defining document for that object class? Section 5.1.3.1, 1st paragraph after LDIF definition: a port number of 2049 is given. Since this is already the default value, why not use a different value? Otherwise, there would be no practical need to include that port number in the FSL creation request. Section 5.1.3.1, 1st paragraph after LDIF definition: up to date - up-to-date Section 5.1.3.2, 2nd paragraph: a - an Section 5.1.3.2, table entry for fedfsNfsVarSub: substituion - substitution Section 5.1.4, 1st paragraph, 1st sentence: a Fileset location - an FSL Section 7.3, 2nd paragraph, Specification value: presumably this will be changed to the RFC number when issued? Section 8, 1st paragraph (definition of Administrator): an - a Section 8, 3rd paragraph (definition of Client): filesystem access - file-access for consistency of usage with the rest of the document. Section 8, 5th paragraph (definition of Fileserver): rather than discussing a filesystem, should this be one or more filesystems? Or is a fileserver limited to exporting one filesystem? Section 8, 8th paragraph (definition of Filesystem Access Protocol): following up on the 3rd paragraph, should this be File-access Protocol for consistency? Section 8, 9th paragraph (definition of FSL), 2nd sentence: fs_location - fs_locations. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com default[4].xml Description: XML document
Gen-ART review of draft-ietf-6man-udpchecksums-04
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 Document: draft-ietf-6man-udpchecksums-04 Reviewer: Peter Yee Review Date: Sep-30-2012 IETF LC End Date: Oct-2-2012 IESG Telechat date: Oct-11-2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] Presuming the assumptions in I-D.ietf-6man-udpzero are valid and agreed to by the community, this document provides an update to 2460 to allow the use of zero checksum UDP packets over IPv6 in certain cases involving protocols tunneled inside of UDP packets. Nits: General: references throughout the document to various Internet Drafts will, of course, need to be cleaned up. General: a comma after e.g. is preferred in American English. Abstract, last sentence: defines - define Section 3, first sentence: tunnelled - tunneled Change the comma after checksum to a period to split the sentence, capitalizing the following there. Then change compute - computing and check - checking for parseability. Section 3, last sentence: cost, - cost. Section 4, 4th paragraph: The below - The points below Also: an UDP - a UDP Section 4, 1st bullet item, last sentence: reception UDP - reception of UDP Section 4, 4th bullet item, 1st sentence: port, destination - port, and destination Also: fields : - fields: (eliminate a superfluous space character) Section 5, paragraph 5 (the replacement text), last sentence: you refer to RFC 2460. That would seem to read oddly when the replacement text is actually inserted into RFC 2460. I think it would be preferable to put in a specific cross-reference to where in 2460 the existing method resides instead of the document itself. Section 5, item 2, last sentence: call, - call Section 5, item 5, 1st sentence: UDP Tunnels - UDP tunnels for consistency. Section 5, item 6, 2 occurrences: Non-IP - non-IP Section 5, item 8, parenthetical: Necessary - necessary. Note the leading space before Necessary that is omitted in the replacement. Section 8 includes one incredibly long run-on sentence. I would suggest splitting it as follows: However, this does not lead to any significant new vulnerabilities as checksums are not a security measure and can be easily generated by any attacker. Properly configured tunnels should check the validity of the inner packet and perform any needed security checks regardless of the checksum status. Most attacks are generated from compromised hosts which automatically create checksummed packets (in other words, it would generally be more, not less, effort for most attackers to generate zero UDP checksums on the host). Authors' Addresses: Unused Fax and URI fields may be omitted. Phone numbers should be presented in international dialing format to facilitate use, e.g., +1 703 501 4376 and +46 10 714 82 87.
Gen-ART review of draft-ietf-ccamp-assoc-ext-05
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 Document: draft-ietf-ccamp-assoc-ext-05 Reviewer: Peter Yee Review Date: Sep-06-2012 IETF LC End Date: Aug-29-2012 IESG Telechat date: Sep-13-2012 Summary: This draft is basically ready for publication, but has a nit that could be fixed before publication. [Ready with nits.] Generally, the diffs between -04 and -05 look fine to me and incorporate my previously offered suggestions. Nit: Section 4, 1st paragraph, 3rd sentence: identifies - identify.
Gen-ART review of draft-ietf-ccamp-assoc-ext-04
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 Document: draft-ietf-ccamp-assoc-ext-04 Reviewer: Peter Yee Review Date: Aug-28-2012 IETF LC End Date: Aug-29-2012 IESG Telechat date: Not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides extensions to the scope of use of the RSVP ASSOCIATION object as well as providing an extended ASSOCIATION object capable of handling a longer Association ID. Nits: In the last example (Symmetric NAT), last sentence: mechanisms - mechanism. Section 2, 4th paragraph (the replacement text): the the - the. Section 3.2.1, 2nd paragraph, 1st sentence: are - is. Alternatively, you could change format to formats. Section 3.2.2, 1st sentence: apply - applies. Section 4.2, 1st sentence: a - an in both occurrences. Section 4.2, last paragraph, 2nd sentence: a - an. Questions: These are questions you may wish to answer but the draft is acceptable without response: 1) In Section 4.2, 4th bullet, is there any implied relationship between the Extended Association ID and the Association ID? Or are they independent values that simply must be matched? 2) Section 4.2, 5th bullet, you make a first and only mention of padding bytes. Are you using a specific method for generating these padding bytes or are they random? Given the matching requirement on ASSOCIATION objects, it might be best to specify the padding generation so that if the object is regenerated, it will still be matched by intermediary nodes. I've presumed that the padding bytes are for meeting the 4-byte multiple requirement, but I don't know if implementations would ever be free to regenerate the object for subsequent transmissions of that object.
Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08
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. This draft is ready for publication as an Informational RFC. Document: draft-ietf-dnsop-dnssec-dps-framework-08 Reviewer: Peter Yee Review Date: 14-July-2012 IETF LC End Date: 17-July-2012 IESG Telechat date: Pending Summary: This draft provides a framework for the creation of DNSSEC Policies and Practice Statements. Major Issues: None Minor Issues: Section 4.4.5 discusses how to handle key compromise. It might be useful to discuss here or somewhere else in the document how the compromise is prevented from recurring if there were no attenuating measures in place beforehand. That might well lead to a revision of the DP or DPS. The draft doesn't really discuss under what circumstances a document should be iterated or amended. Of course, that might be considered a meta issue and outside of the scope of the DP or DPS proper. Nits/editorial comments: In Section 4.6, behaviour is spelt in the British manner. While most assuredly not incorrect, you may wish to spell it in the American manner. Serial commas are used inconsistently. Nothing as egregious as the following example, however. ;-) http://grammarnowtips.wordpress.com/2011/01/08/a-case-for-the-serial-comma/
Gen-ART review of draft-ietf-ippm-twamp-value-added-octets-03
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-ippm-twamp-value-added-octets-03 Reviewer: Peter Yee Review Date: 28-June-2012 IETF LC End Date: 28-June-2012 IESG Telechat date: Pending Summary: This draft describes an extension to the TWAMP protocol for handling packet trains which are used to quantify network capacity metrics. The document is ready for publication as an informational RFC. Major Issues: None Minor Issues: None Nits/editorial comments: Section 2, in the paragraph right after the two bullets: measurements - measurement. Section 3, 5th paragraph, 4th sentence (The method to measuring the UDP delivery rate may also require the packet loss.) left me confused. Did you mean something like The method for measuring the UDP delivery rate may also require the rate of packet loss.? Percentage? Count? Next paragraph, 2nd sentence: rate - rates. Next paragraph, same change. Section 4, 2nd paragraph, 2nd sentence: require - requires. Section 5, 2nd paragraph, 1st sentence: of first - of the first. Section 5, 3rd diagram, it's not utterly clear that the Reserved field includes the two bits from the last octet on the previous line. (Yes, I do understand that it's really hard to indicate the connection in an ASCII diagram!) The text implies that must be the case, but only owing to the size of the field. Section 5.1, second to last paragraph, last sentence: If I bit - If the I bit. Section 5.2, 2nd bullet, 2nd sub-bullet, 2nd sentence: the another - another. Section 5.:, to estimate or calculate - to estimating or calculating? Section 5.3, second sentence: to identify - of identifying. Section 6, 1st paragraph: direction - directions. Section 6, 2nd paragraph, 2nd sentence: the whole trains - whole trains. Section 6, 2nd paragraph, last sentence: of new field - of a new field.
Gen-ART review of draft-ietf-mile-template-04
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-mile-template-04 Reviewer: Peter Yee Review Date: 26-May-2012 IETF LC End Date: 28-May-2012 IESG Telechat date: 07-June-2012 Summary: This draft gives guidance on creating extensions to IODEF (RFC 5070). The document is ready for publication as an informational RFC. Major Issues: None Minor Issues: None Nits/editorial comments: 1) There are two occurrences of the statement Note that this list is present as of publication time. It might be clearer to use the word current in place of present. 2) Section A.3, insert section after This in the third sentence. 3) Section A.8, drop section in the second sentence. 4) Regarding the example in Appendix B, RFC 6116 uses the e164.arpa domain, not e164.int. You'll probably want to switch to the former.
