On Fri, 6 Jun 2008, Eric Gray wrote: > 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...
By strange I was referring to (1) being chosen to doing a re-review and (2) reviewing the whole draft again (instead of just changed parts since last review). To me it would seem that it would be more useful for a reviewer to review a new draft rather than to look the same one again in completeness. But I don't know the methology used for reviewer selection in Gen-ART; maybe there is a good reason for this. If you had only been looking at the changed parts, that would not have been a surprise (and I believe you already did that after the previous revision). Pekka >> -----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
