Spencer Dawkins' No Objection on

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-multimob-pmipv6-source-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/



----------------------------------------------------------------------
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"?

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).

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.

MNs, as mobile multicast listeners in the PMIPv6 domain will in
general not actively terminate group membership prior to departure.

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?

a reliable and timely manner (see [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies).

[Thomas C. Schmidt]

Hi Spencer,

thanks for the review and comments on presentation issues. Please see
inline.

Post by Spencer Dawkins
Spencer Dawkins has entered the following ballot position for
draft-ietf-multimob-pmipv6-source-08: No Objection
----------------------------------------------------------------------
----------------------------------------------------------------------
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.

:-)

Post by Spencer Dawkins
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."

Post by Spencer Dawkins
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 ;)

Post by Spencer Dawkins
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"

Post by Spencer Dawkins
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"

Post by Spencer Dawkins
a reliable and timely manner (see [RFC6224] for requirements on
PMIPv6-compliant implementations of MLD proxies).

We will update the draft accordingly.

Best,

thomas

[Spencer Dawkins at IETF]

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 <

Post by Thomas C. Schmidt
Hi Spencer,
thanks for the review and comments on presentation issues. Please see
inline.

Post by Spencer Dawkins
Spencer Dawkins has entered the following ballot position for
draft-ietf-multimob-pmipv6-source-08: No Objection

----------------------------------------------------------------------

Post by Spencer Dawkins
----------------------------------------------------------------------
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)

Post by Spencer Dawkins
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

Post by Spencer Dawkins
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

Post by Spencer Dawkins
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
"MLD proxy implementations at MAGs SHOULD automatically extinct multicast
state on the departure of"
Consequently,

Post by Spencer Dawkins
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.
"implementations of peering-enabled proxies SHOULD take particular care on
keeping IP configurations consistent"
a reliable and timely manner (see [RFC6224] for requirements on

Post by Spencer Dawkins
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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: [phone] °