[Gen-art] Gen-ART review for draft-salgueiro-dispatch-websocket-sipclf
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: http://www.ietf.org/id/draft-salgueiro-dispatch-websocket-sipclf-01.txt Reviewer: Dan Romascanu Review Date: 6/2/2014 IETF LC End Date: 6/10/2014 IESG Telechat date: not scheduled yet Summary: This document which updates the SIP Common Log Format (CLF) defined in RFC 6873 with a new Transport Flag for the RFC 7118 SIP WebSocket transport is ready. Major issues: None Minor issues: None Nits/editorial comments: None ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt
On May 30, 2014, at 5:11 PM, Warren Kumari war...@kumari.net wrote: On Mon, May 19, 2014 at 10:15 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: (sorry, retransmission with corrected address) Yeah, I do that as well, especially with directorate reviews... I am the assigned Gen-ART reviewer for this draft. Thank you, A: for doing the review, and B: doing it early. Apologies for taking so long to respond - I was procrastinating, and also wanted to check with my co-author before responding. Unfortunately I was unable to reach him on Jabber (I seem to remember he had some travel), and so anything stupid below is my fault, not his. 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-dnsop-delegation-trust-maintainance-13.txt Reviewer: Brian Carpenter Review Date: 2014-05-20 IETF LC End Date: 2014-05-26 IESG Telechat date: Summary: Almost ready Minor issues: - 1. Introduction ... Any manual process is susceptible to mistakes and / or errors. Also susceptible to social engineering or malicious leaks, I think. There's a fairly strong security argument for getting humans out of the process. Yes. But, assuming it is OK with you / the IESG, I'll not mention that -- while true, it seemed like a distraction, and some of the customers (registrars) are kinda sensitive about the whole social engineering issue :-) 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions ... it is up to the consumer of the records to translate that into the appropriate add/delete operations in the provisioning systems Not clear here whether this is expected to be an automated or manual process. On the parent side it is intended to be automated -- it *could* be done manually, but probably will be an automated (the child side can be either automated or manual, see below). ... it is a replace operation, and it is up to the software that consumes the records to translate that ... Better / clear? Yep If no CDS / CDNSKEY RRset is present in child, this means that no change is needed. Not clear here how we ensure that update is performed exactly once. See below. I think I've clarified that some (see below, and will post an updated version soon (also incorporating comments from SM, and Olafur away at moment, want to key his ACK on text). This is if the parent polls, and sees no CDS / CDNSKEY, it goes back to sleep. The reason we added this clarification is: 1: Initially no domains will have CDS records, even those that do currently have DS records. 2: Without this clarification, the parent might think The CDS means 'Make the DS for the child look like what the child published. The child published nothing, so, obviously, I should remove the DS' 3: Now everyone who has a DS has none, and they come shout at us :-) 4. Automating DS Maintenance With CDS / CDNSKEY records CDS / CDNSKEY resource records are intended to be consumed by delegation trust maintainers. The use of CDS / CDNSKEY is optional. I think that could be OPTIONAL. DONE. The child SHOULD publish both CDS and CDNSKEY resource records. Given the previous sentence, I think this needs to be If the child publishes either the CDS or the CDNSKEY resource record, it SHOULD publish both.. DONE. 4.1. CDS / CDNSKEY Processing Rules ... If there are no CDS / CDNSKEY RRset in the child, this signals that no change should be made to the current DS set. This means that, once the child and parent are in sync, the Child DNS Operator MAY remove all CDS and CDNSKEY resource records from the zone. Does that mean the the child MAY/SHOULD/MUST monitor what the parent is publishing in order to automate this process? If not, you are calling for a manual operation. (The text in section 5 is repetitious, by the way, but still doesn't clarify this.) Hmmm. We are not really expecting that children will do this very often / ever -- it is allowed, but extra work for the child. The (IMO) most likely way that this will happen is that a child will publish a new zone file without the record in, either because they didn't recognize it or because some post-processing script actually adds the record, and the post-processing script didn't run (or something similar). The child can check and see if the parent is publishing is the same as it requested, If and Only If that is true then the child can remove the records. Some tool vendors have told us that they will never do removal, but others plan on performing it. The child MUST monitor parent in order to perform a key rollover, as it should not perform the rollover operations until it is safe based on the information that the parent is publishing in the DS set. However, it is allowed, and so we
Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01
Meral - Thanx for your review. Responses inline. From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com] Sent: Monday, June 02, 2014 5:46 PM To: draft-ietf-isis-fs-lsp@tools.ietf.org; gen-art@ietf.org Subject: Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01 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-isis-fs-lsp-01 Reviewer: Meral Shirazipour Review Date: 2014-06-02 IETF LC End Date: 2014-06-03 IESG Telechat date: 2014-06-12 Summary: This draft is ready to be published as Standard RFC but I have some editorial comments. Nits/editorial comments: -[Page 5], Section 2, typo , identifes--identifies LES :Corrected. -[Pages 8, 10, 12], typo: sub-TLVss-sub-TLVs LES: Corrected. -[page 6] section 2.2, an example would be useful for: o The eight bit type is encoded as an unsigned 16 bit integer LES: I have modified the bullet point to read The eight bit type is encoded as an unsigned 16 bit integer where the 8 MSBs are all 0 o The eight bit length field is replaced by the 16 bit length field LES: I am not sure what you expect as an example. Because the length field is 16 bits instead of 8, the length field can take on values greater than 255 - a point which which is explicitly made in the next bullet. The numerical value used in the length field in an Extended TLV is not limited to the values used in Standard TLVs (= 255) even when the type is a Standard TLV code point. -[Page 14], Section 5 the sentence could be more readable with the suggested change: old: Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope flooding of the FS-LSPs may be compromised. suggested:(added , then) Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope, then flooding of the FS-LSPs may be compromised. LES: Accepted -Suggestion, when reference to [IS-IS] is made, it would be very useful to point to the right section as well, when possible. LES: There is not a single section which is applicable to the references. In most cases there are multiple sections which apply - so I don't think your suggestion is practical. Les Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.comhttp://www.ericsson.com ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01
Hi Les, Thank you for the changes and explanations. Best Regards, Meral From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Monday, June 02, 2014 6:10 PM To: Meral Shirazipour; draft-ietf-isis-fs-lsp@tools.ietf.org; gen-art@ietf.org Subject: RE: Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01 Meral - Thanx for your review. Responses inline. From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com] Sent: Monday, June 02, 2014 5:46 PM To: draft-ietf-isis-fs-lsp@tools.ietf.orgmailto:draft-ietf-isis-fs-lsp@tools.ietf.org; gen-art@ietf.orgmailto:gen-art@ietf.org Subject: Gen-ART Last Call review of draft-ietf-isis-fs-lsp-01 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-isis-fs-lsp-01 Reviewer: Meral Shirazipour Review Date: 2014-06-02 IETF LC End Date: 2014-06-03 IESG Telechat date: 2014-06-12 Summary: This draft is ready to be published as Standard RFC but I have some editorial comments. Nits/editorial comments: -[Page 5], Section 2, typo , identifes--identifies LES :Corrected. -[Pages 8, 10, 12], typo: sub-TLVss-sub-TLVs LES: Corrected. -[page 6] section 2.2, an example would be useful for: o The eight bit type is encoded as an unsigned 16 bit integer LES: I have modified the bullet point to read The eight bit type is encoded as an unsigned 16 bit integer where the 8 MSBs are all 0 o The eight bit length field is replaced by the 16 bit length field LES: I am not sure what you expect as an example. Because the length field is 16 bits instead of 8, the length field can take on values greater than 255 - a point which which is explicitly made in the next bullet. The numerical value used in the length field in an Extended TLV is not limited to the values used in Standard TLVs (= 255) even when the type is a Standard TLV code point. -[Page 14], Section 5 the sentence could be more readable with the suggested change: old: Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope flooding of the FS-LSPs may be compromised. suggested:(added , then) Even when all routers in a given scope support FS PDUs, if not all routers in the flooding domain for a given scope support that scope, then flooding of the FS-LSPs may be compromised. LES: Accepted -Suggestion, when reference to [IS-IS] is made, it would be very useful to point to the right section as well, when possible. LES: There is not a single section which is applicable to the references. In most cases there are multiple sections which apply - so I don't think your suggestion is practical. Les Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.comhttp://www.ericsson.com ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
