I think there's a misunderstanding about the spreadsheet information. This doc was on the Telechat for June 5th, so the re-review was in anticipation of the telechat, per the assignments: http://www.alvestrand.no/ietf/gen/art/reviewers-080605.html In looking at columns in the spreadsheet, which has evolved overtime to cover last call reviews, I should rename the current "Status" field to read "Past Review" and change the default from "New" to "None" to avoid this sort of confusion going forward.
I will make those changes when I'm back in the office next week. Sorry for the confusion this caused. Thanks, Mary. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Gray Sent: Friday, June 06, 2008 6:09 AM To: Pekka Savola Cc: [email protected]; James Lingard; David Ward Subject: Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-pim-lasthop-threats-04.txt Pekka, You're right about a previous review, but this was listed as a re-review on my queue at - http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html - see for yourself. I am not sure what is strange about it. If you think there are no changes required, then there is nothing to add to the RFC editor's note that exists already. This is a "ready to publish" summary, indicating progress relative to the previous review (an "almost ready to publish" review). As for the timing, if you look at my queue at the above site, you will see that it indicates a (re-)review was due yesterday; unfortunately, I did not find that out until today. I guess I needed to "refresh" the browser window, which I did as soon as I saw Mary's E-Mail this morning... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2008 6:57 AM > To: Eric Gray > Cc: James Lingard; David Ward; [email protected] > Subject: Re: Gen-ART Last Call Review of > draft-ietf-pim-lasthop-threats-04.txt > Importance: High > > On Fri, 6 Jun 2008, Eric Gray 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 resolve these comments along with any other Last > Call comments > > you may receive. > > > > > > Document: draft-ietf-pim-lasthop-threats-04.txt > > Reviewer: Eric Gray > > Review Date: 6/6/2008 > > IETF LC End Date: 6/5/2008 > > IESG Telechat date: Unknown > > This is a bit strange, as you already reviewed -03 version > about a month > ago :-). The timing is also a bit difficult as the document > was approved > yesterday, pending an RFC-editor note. I'm not sure how to deal with > these mostly editorial comments. > > I don't understand the second comment you're making. Wrt the > authentication/authorization issue, both are required even if > we mention > just authorization, but depending on what your assumptions > are about the > confidentiality, integrity etc. of multicast data, this is > not a PIM issue > as such. The reason it's even discussed in 3.3 is that if > your security > model just expects the routing protocols to handle everything for you > (instead of using group security etc. extensions provided by e.g. > RFC3740), you're going to be surprised. From PIM perspective this is > about only accepting PIM signalling from correct nodes -- > maybe this is > authentication even if it is authentication by IP address, > IPsec SA, etc. > > Pekka > > > Summary: > > > > This draft is essentially ready for publishing as an Informational > > RFC. There are minor comments and NITs below which may result in > > minor editorial changes which could be handled as RFC Editor notes. > > > > Comments: > > > > This draft was exceptionally easy to read and understand. > > > _____________________________________________________________________ > > > > In the introduction, instead of "host acting as an illegitmate > > router", perhaps it should read "any device acting as an ..."? > > > > Later (in the very next section, for example), you say things > > like - > > > > "The attacking node may be either a malicious host or an > > illegitimate router." > > > > - pointing out that (the second occurence of) "host" in the 3rd > > paragraph is problematic (since it may be something other than > > a host). > > > _____________________________________________________________________ > > > > In the second paragraph of section 2.1, "[RFC3704]" should be > > "(see, for example, [RFC3704])" - I am fairly certain there are > > other ways to prevent address spoofing (for instance, this RFC > > updates, but does not replace, RFC 2827 - which actually is a > > more generic reference). In fact, you may wish to replace RFC > > 3704 with RFC 2827 (even as an example) simply because it is a > > more generic example, but that is your call (especially given > > there are other points at which you also refer to RFC 3704). > > > > NITs: > > ==== > > > > In the abstract, "connecting hosts" -> "connecting to hosts"? > > > _____________________________________________________________________ > > > > In the 1st paragraph of the introduction, should "authorization" > > be "authentication"? Since you also use the same terminology in > > section 3.3 (and possibly elsewhere), this may not actually be a > > NIT (it may be somewhat more than an editing issue). > > > > I believe the potential for confusion comes up in section 3.3 - > > where it is pointed out that there are deployment models where > > authorization and authentication are tied together (assuming I > > correctly understand the issue raised in the 5th paragraph) for > > paid services (presumably something like IPTV). It is not clear > > in what way "authorization" is a legitimate concern with the PIM > > protocol (or its associated security vulnerabilities) - opposed > > to a concern for the application of PIM. I am reasonably sure > > that - if you separate authorization and authentication - it is > > authentication that needs to be a PIM concern. > > > _____________________________________________________________________ > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
