Hi, Thomas, These are all fine for me, and thank you.
You might want to make sure your AD is ready for a revision, of course. Thanks, Spencer On Monday, March 31, 2014, Thomas C. Schmidt < [email protected]> wrote: > Hi Spencer, > > thanks for the review and comments on presentation issues. Please see > inline. > > On 25.03.2014 17:27, Spencer Dawkins wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-multimob-pmipv6-source-08: No Objection >> >> > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have a couple of questions about text clarity. Please consider them, >> along with any other comments you receive from other reviewers. >> >> And I should say that MIP/PMIP drafts I've often read have been dense for >> me, and this one is clearer than most - thank you for that. >> >> > :-) > > 4.3.2. Operations of PIM in Phase One (RP Tree) >> >> Source handover management in PIM phase one admits low complexity and >> remains transparent to receivers. In addition, the source register >> tunnel management of PIM is a fast protocol operation and little >> overhead is induced thereof. >> ^^^^^^^^^^^^^^^ >> >> I didn't understand this text clearly. Is it saying something like >> "little overhead is introduced"? >> >> > Yes, we reworded: "... PIM is a fast protocol operation that introduces > little overhead." > > 7. Security Considerations >> >> In addition to proper authorization checks >> of MNs, rate controls at routing agents and replicators MAY be >> required to protect the agents and the downstream networks. In >> ^^^^^^^^ >> >> is this "may be needed"? The passive voice doesn't make the text easy to >> parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separate >> issue). >> >> > Yes, you're right: "may be needed" is what we wanted to say ;) > > particular, MLD proxy implementations at MAGs SHOULD carefully >> procure for automatic multicast state extinction on the departure of >> ^^^^^^^ >> >> This word doesn't fit (a quick google of online directionaries pointed >> toward "procure" as obtaining something by special effort, for example). >> I wondered if you meant "probe", but I'm guessing. >> >> > "Probe" would refer to a special solution to achieve this clean-up of > state. We would reword: > > "MLD proxy implementations at MAGs SHOULD automatically extinct multicast > state on the departure of" > > > Consequently, >> implementations of peering-enabled proxies SHOULD take particular >> care on maintaining (varying) IP configurations at the downstream in >> ^^^^^^^^^ >> I don't understand what "varying" means in this context (my first guess >> was that it was being used as a synonym for "maintaining", which didn't >> work). Is it needed at all? >> >> > The focus here is on the changing IP connectivity at a MAG's downstream. > We reword: > > "implementations of peering-enabled proxies SHOULD take particular care on > keeping IP configurations consistent" > > a reliable and timely manner (see [RFC6224] for requirements on >> PMIPv6-compliant implementations of MLD proxies). >> > > We will update the draft accordingly. > > Best, > > thomas > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 > ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 > ° >
_______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
