Re: [Gen-art] [OPSAWG] Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Speaking as a contributor I support option b) - (actually a+b) Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juergen Schoenwaelder Sent: Thursday, June 26, 2008 11:00 AM To: David Harrington Cc: 'General Area Review Team'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco very-02.txt On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/opsawg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
a+b dbh -Original Message- From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 4:00 PM To: David Harrington Cc: 'Randy Presuhn'; 'General Area Review Team'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco very-02.txt On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pwe3-pw-atm-mib-05.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-pwe3-pw-atm-mib-05.txt Reviewer: Francis Dupont Review Date: 2008-06-24 IETF LC End Date: 2008-06-24 IESG Telechat date: unknown Summary: Not Ready Comments: I have (too) many editorial concerns. Even the MIB part is to be processed by machines (vs. humans) it should be written with a minimal care. In details: - TOC page 2: Acknowledgements - Acknowledgments - 1 page 3: Network(PSN) - Network (PSN) - all abbrevs must be introduced (or replaced when they are used once). For instance PWE3 has to be introduced... - AN ATM - An ATM - MIBS - MIBs (twice. The rule itself doesn't matter but there should be a rule and this rule must be applied). - 3 page 4: a ATM - an ATM (twice) - net - network - BTW IMHO you should introduce some ATM terminology too, for instance VP and VC. - 5 page 5: VP and VC abbrevs should be introduced (including the VPI/VCI related abbrevs). - cells transmit - Cells transmit - replace OAM and ILMI by their definitions. - 6 page 6: is it PWE MIB or PWE3 MIB? - 8 page 7: I suggest a ':' after Table (and before the first '-'). - 1: 1 - 1:1 (many) - 9 page 8: please add the Country USA in addresses. - 9 page 9: the RFC Ed. comments have a string problem. - 9 page 11 and 12: please put a '.' at the end of description strings. (also pages 14 (twice), 17, 18 (twice), 20) - 9 page 12: (3).Unless - (3). Unless - 9 page 14: description strings should get an uniform identation (twice). (and pages 30, 32) - --Generic - -- Generic - 9 page 15: interuppted - interrupted - 9 page 16: .e.g. - e.g., - 9 page 17: please use the same case for all V[pP][iI] and V[cC][iI] (many) (and page 20) - 9 page 18: a ATM - an ATM (and page 21 - 9 page 33: for N:1 - for N:1 - 10 page 33: SNMPV3 - SNMPv3 - 10 page 34: the 'even if 'even then' seems strange (perhaps it is just something I don't know?) - 12.1 page 35: please put the name of the drafts. - 13 page 36: Acknowledgements - Acknowledgments Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-isis-rfc2763bis-00.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-isis-rfc2763bis-00.txt Reviewer: Francis Dupont Review Date: 2008-06-25 IETF LC End Date: 2008-06-23 IESG Telechat date: unknown Summary: Almost Ready Comments: I have some editorial concerns: - first, as it is an update it should be fine to provided a temporary (i.e., marked as to be removed before publication) section about the changes from the RFC 2763. This would refrain me to raise concerns shared by the RFC 2763... - Copyright page 1: if (and *only* if) you issue a new version don't forget to update the year. - Abstract page 2: put Abstract from center to left - 1 page 4: a reference for IS-IS should be fine. And please add a statement about the use of IS-IS as an IP routing protocol (or I'll ask why you don't discuss about X.500 in place of DNS :-). - 1 page 4: the abbrev LSP should be introduced. - 2 page 5: there is a DNS RR for CLNS NSAPs, it is the NSAP RR. So I propose to replace A and PTR by a text like address and reverse. - 2 page 5: CLNS and TLV abbrevs should be introduced, and IMHO before section 2. - 3 page 5: the FQDN (Fully Qualified Domain Name) abbrev should be introduced. BTW the subset of the FQDN doesn't make sense, it is just a Domain Name. - 3 page 5: you have to be more accurate about the representation of DNs, obviously you'd like the textual representation (not the DNS on wire one with name compression, wouldn't you?) - 4 page 6: it's - its - 6 page 6: Others to be provided So provide some? - 8.2 page 9: RFC 2119 should be normative. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt
Thanks - that seems like a useful addition, and the other changes look fine to me also. Please submit, with this one extra change included. Colin On 24 Jun 2008, at 17:08, [EMAIL PROTECTED] wrote: Futemma-san, The proposed new version of the draft looks ok to me - it has dealt with all of the concerns in the Gen-ART review. I have one comment on the changes. The second paragraph of Section 8 now recommends clearing the saved mh_id (and I would think also the saved header) if the decoder detects an inconsistency between the header and payload. It would be useful to repeat that recommendation in Section 4.2 (so that all of the situations in which the receiver should clear saved information are explained in that section) with a recommendation to see Section 8 for more explanation. Thanks, --David -Original Message- From: Satoshi Futemma [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 11:16 PM To: Black, David Cc: gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Gen-ART review of draft-ietf-avt-rtp-jpeg2000- beam-10.txt Dear, An attachment is the changes of draft-ietf-avt-rtp-jpeg2000-beam we propose. The changes are: - The abstract became more clear and added RFC editor note. - added the algorithm to calculate priority value of progression based order in Section 3.2 - the media type video/jpeg2000 eppeared in Section 5 and Section 7. - Changed the last sentence in 8. Security Section If they are ok, I will submit the document. Best Regards, Futemma [EMAIL PROTECTED] wrote: 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-avt-rtp-jpeg2000-beam-10.txt Reviewer: David Black Review Date: 16 June 2008 IESG Telechat date: 19 June 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The authors have only partially addressed the open issues noted in the Gen-ART review of the -09 version. More work is needed: [1] The review of the -09 version stated: Section 3.2 doesn't provide enough information to calculate a packet priority value from layer, resolution and component values. In fact the example it gives appears to be simple enough to also be an example of the component based ordering defined in Section 3.5. Section 3.2 needs to explain how the priority value is calculated and use a more complex example to illustrate the results of the calculation. In my opinion, Section 3.2, while improved, is still not clear enough to be interoperably implemented in its current form. A more complex example is now used, but the text does not state the the algorithm used to generate the priority, nor does it provide the specific algorithm for the example. The general algorithm is that the ordering is based on the triple layer, resolution, component and the minimum priority is 1, so, if - There are ltotal layers (layer value range is 0 to ltotal-1) - There are rtotal resolutions (resolution value range is 0 to rtotal-1) - There are ctotal components (component value range is 0 to ctotal-1) then for a triple lval, rval, cval, - priority = 1 + cval + (ctotal*rval) + (ctotal*rtotal*lval) and for the example where ltotal=1, rtotal=2 and ctotal=3, - priority = 1 + cval + 3*rval because lval=0 hence the ctotal*rtotal*lval term is zero (3*2*0) and hence does not contribute to the priority computation. [2] The review of the -09 version stated Section 4.1 contains this problematic text: An initial value of mh_id MUST be selected randomly between 1 and 7 for security reasons. This has been partially addressed. While section 2.1 now requires that the initial value of mh_id always be zero, the above problematic text remains, and still needs to be removed from Section 4.1. In addition, Security Considerations paragraph on mh_id concludes with a rather cryptic statement that Care should be taken to prevent implementation bugs with potential security consequences. Either more specific guidance should be given, or the entire paragraph should be removed, as mh_id does not appear to have any security value. In addition, there is a new open issue: [3] Section 7 does not appear to instruct IANA on what is to be done. It appears that IANA should add the new parameters in section 5 to the existing registration of a media type, but neither section 5 nor section 7 tells IANA what do to or which media type registration is to be modified. Nits: Reference [1] has still not been corrected. The Gen-ART review of the -09 version stated: Reference [1] should reference the
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED] Cc: 'Randy Presuhn' [EMAIL PROTECTED]; 'General Area Review Team' gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 26, 2008 12:59 AM Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery perhaps with a note that this information can get out in other ways b) declare that this potential information leakage is a feature that is RECOMMENDED to support I'd quibble with the to support - we're not talking about an implementation decision, but rather a deployment / usage decision, since the VACM configuration is what would determine how much leaks, beyond what the protocol itself exposes. c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard ... So I agree in spirit with a+b Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Assignments for 03 July 2008
Hi all, Here's the link to the assignments for the July 3rd telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-080703.html 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 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, July 1st, per the review guidelines: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Reviews received after that time will still be included in the spreadsheet for that week, but they are far less likely to be considered as input for the telechat itself, due to the time constraints that Russ has with the telechats being on Thursday mornings (EST). And, obviously reviews received later than Wednesday evening will likely not be included in the spreadsheet until I do the assignments on Thursday evening, due to my time constraints. Thanks for your consideration of these issues. Also, there will be an exception this week in terms of updates to the spreadsheets. I will not be able to capture any reviews sent after Sunday (June 29th) MST morning as I lose Internet access until Friday evening July 4th. So, please do make sure that your postings make it to the gen-art mailing list. Brian Carpenter is also a mailing administrator, so hopefully he can handle any of those issues. Mary. --- 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: dd Month 2008 Summary: Comments: ___ 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 - 26 June 2008
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-080626-lc.html 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. Note: I'm still using the temp server. I have rekeyed and still can't Log into gen-art server and have not had the chance to track down the problem. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-isis-rfc2966bis-03.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-rfc2966bis-03.txt Reviewer: Brian Carpenter Review Date: 2008-06-27 IESG Telechat date: 2008-07-03 Summary: Ready, minor questions Comments: This does exactly what its abstract promises. Note - Tony Li agreed with the following Last Call comments, but I don't believe they are show stoppers. I'm not certain that the RFC 2119 keywords have been applied consistently. For example, this seems as if it should be MUST NOT: However, to prevent routing-loops, L1L2 routers must not advertise L2-L1 inter-area routes that they learn via L1 routing, back into L2. and maybe this should be SHOULD: Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. This will matter if the document is later promoted to Draft Standard (which for such an old specification could be quite soon). 6. Security Considerations This document raises no new security issues for IS-IS. Maybe add a reference to the Security Considerations of RFC 1195?___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-pwe3-enet-mib-13
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-pwe3-enet-mib-13.txt Reviewer: Brian Carpenter Review Date: 2008-06-27 IESG Telechat date: 2008-07-03 Summary: Ready Comments: I found the introductory sections to be rather clear, considering the complexity of PWE3. I have not reviewed the MIB objects in detail. Comments should be made directly to the PWE3 mailing list at [EMAIL PROTECTED] This sentence should be deleted during final editing.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
