Re: Last Call on draft-ietf-netlmm-proxymip6
Thanks for your kind words and sorry for taking my time to answer. Please,
find below some thoughts, comments, and questions to your mail.
On 2/15/08 3:55 AM, "ext Ted Hardie" <hardie(_at_)qualcomm(_dot_)com> wrote:
Thanks for your reply; some comments inline.
At 1:17 PM -0800 2/14/08, Soininen Jonne (NSN FI/Espoo) wrote:
I agree with you on the notion that we shouldn't publish anything that we
know already that will need fixes or does not work properly for the intended
use at this point. However, I think it is completely proper to revise
specifications based on operational experience - ever rather quickly after
publishing as a PS. Though, seldom done I have understood it is has been
even the original idea of the three step standardization process.
I agree that we should be able to revise specifications very quickly.
RFC 2026 is pretty clear, though, that we shouldn't publish things that
we believe are missing important pieces:
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.
I agree, and I think I wrote that as well in my mail. We shouldn't publish
PS'es with known technical omissions. Instead we should fix the omissions or
problems when we find them.
However, I don't think we have such technical omissions in the current
draft. I think the draft - due to extensive review and long debates - is in
a pretty good shape.
The tricky bit here is that the requirements placed on this have shifted
since the work was chartered, and it is not clear whether the technical
omissions here are meant to be consonant with the original charter,
even though they don't meet the technical requirements of the current
I think this is the general problem we seem to have sometimes in the IETF.
We charter things for a year's worth of work, but in the end the work takes
quite some years more than that. The requirements have shifted and the
original scope doesn't fit the solution needed in the end. Hence,
flexibility is needed.
I think "the right thing to do" would have been to recharter the work
already earlier to fit the right problem. However, it didn't seem worth the
effort earlier as the main focus still should be on the technical work.
As you should also note in reading my mail, I am encouraging the IESG to waive
this requirement in order to get this document out in a timely fashion,
but with a forward pointer in place that would allow us to indicate
we intend to fill the empty slot in the toolbox and, generally speaking,
where someone should eventually look for the tool.
I'm happy that you also find the flexibility needed in this case. However,
I'm not really sure what you are referring to with your comment about an
empty slot in the toolbox. Which slot in your mind seems to be empty?
I'm glad that you also support MN-AR going forward. I also hope that you
are too pessimistic on the possibility of making a general mechanism.
While the networks you cite are certainly complex and will no doubt have
systems engineering documents which describe exactly how to use PMIP
in their environments, that's not the work I'm suggesting the IETF should take
on. Instead, I'm suggesting that we need and should complete the work
of describing a general mechanism specifying how a mobile node
talks to a mobile access gateway. That may well not replace the systems
engineering work needed by the current customers for PMIP, but it will make
the work more generally useful. It may even be in the fullness of time
that the mobile-node to MAG signalling will be used in those environments,
once it is generally available.
I am generally a pessimist. I have heard that a pessimist is never
disappointed. However, I think in this particular case I would say that it
is not really pessimism. Practically the MN-AR interface is very link layer
dependent. Different systems have quite different link layers and might have
rather different procedures. So, I don't think a general view is really
possible, or perhaps even desirable.
I have to say that I don't see much use currently to specify a standard for
MN-AR signalling in the IETF. Not at least currently. However, perhaps I'm
missing something here.
Thank you for your comments, and I guess I forgot to thank you for your
review of the document as well!
Thanks again for your thoughtful reply,
I cross-posted this to the netlmm mailing list to make sure everybody knows
this discussion is going on.
On 2/14/08 3:01 AM, "ext Ted Hardie" <hardie(_at_)qualcomm(_dot_)com> wrote:
Summary: One issue needs resolution.
First, let me start by saying that -09, which was put out for Last Call, was
improvement over the -08. I normally read Last Call documents using a diff
and the number of really solid additions in this update was quite high. I
surprised, given the extent of the new text, that there was no WG last call,
I assume that the WG is reviewing the changes in parallel. I assume that
of -10, which came out during the last call, was a response to one or more
from the WG or solicited experts.
To call out one particular improvement, I found the update's language
multi-homing much clearer, and I believe the risk of assignment of the same
address to multiple interfaces is much reduced in this version. Given the
potential consequences (watching your stack scream "I'm melting! I'm
as someone entertainingly put it), that's a really good thing.
There are still some opportunities for editorial update, and I hope that as
the IESG enters its discussions that some of those are targets for
I'd particularly like to see even more clear light on the description in
bullet 4 of Section 220.127.116.11, as "predictably knows" is not as clean as
it might be. (The current sentence is: "The Handoff Indicator field MUST be
value 1 (Attachment over a new interface), if the mobile access gateway
knows that the mobile node's current attachment to the network over this
interface is not as a result of an handoff of an existing mobility session
the same interface or through a different interface), but as a result of an
attachment over a new interface. "). But that is really a language clarity
problem, at least I hope, at this point.
The big issue that remains is actually one that starts from the scope creep.
I was on the IESG during the period when this charter was approved, and it
was clear at the time that some of the limitations being put in were
to focus NETLMM on cases where nodes were re-associating at layer 2 with the
same network. The charter says, for example: "The protocol will not
to hide handover between two separate interfaces on the mobile node.".
This document (and, as I understand it, the working group discussion for
has gone beyond that initial scope. A good portion of this document's
is because it does handle the multi-interface case. While it would have
to have the charter updated to state the new scope, I don't personally have
problem with the scope. I am concerned, however, that the design
changed with that new scope and that other parts of the charter are limiting
folks' understandings of what can be done here, when those restraints are
salient for the single layer 2 initial scope.
To put it simply, given the inter-technology handoff, signalling from the
to the network is one of the clearest and most likely to be interoperable
the correct behavior in some of the base cases. At the moment, because the
for setting the handoff indicator do not necessarily involve the mobile node
appear to be below IP where between the mobile node and the networ), a
node with multiple interfaces will not always be able to signal that it
desires handoff or
prefers multihoming. The document is now clear that in that case it gets
multihoming. That's a tremendous advance over the previous state. But the
big win here would be to enable the signaling . As it stands, the
on the handoff indicator provided by the MAG, but the document does not
any information on how the MAG will know this information. There certainly
be cases where a network architecture will allow the MAG to use layer 2
or other mechanisms, but there will also be cases where that set of
is inconsistently available. Adding the higher-layer signalling makes this a
I'm concerned that sending the document out in its current state will either
a quick re-spin at PS to enable this once the issues arise in deployment or
that some of
the contexts in which this is intended to be used will work around the
in ways which will hinder an interoperable, long-term deployment.
I am very conscious, however, that there is considerable time pressure on
document. I propose the following as a way forward which should not add any
1) Add an explicit, normative reference to draft-netlmm-mn-ar (which would
need to be revived) as the basis for a forthcoming above-IP signalling
using an RFC-Editor's note.
2) Put draft-netlmm-mn-ar on the standards track, but make an explicit
downref statement for this document to the internet-draft. This would allow
this document to progress without delay, but provide a reference for those
will be deploying this in contexts which do not have the same
network management of the networks for which this is urgent. When
draft-netlmm-mn-ar is published, it would be available, of course, to both
3) Go ahead with IESG processing on this document on the basis of the
date, with the understand that the IESG would reconsider only if the second
with the explicit downref raised new issues. IESG consideration prior to
end of a Last Call already occurs in some cases, and it certainly could be
used in this case to meet the
I'm aware that the charter states that there should be no signalling
between the mobile and the network. In the context of the original design
that should have been read quite strictly. In the context of the current
I believe we have to distinguish between making something required and
a standard way of handling something in the inter-technology case. I do not
that adding this normative reference would make it required. It would
show how the IETF intended to meet the need for an interoperable mechanism
for signalling where the mobile node had the capability and interest.
not, the basic mechanisms in this draft would suffice.
I understand that this has been an active, and at times contentious, area of
and I do not want this last call comment to fan any old flames. As an APPs
that I'm in favor of pretty much anything that reduces the need for updated
and all the concomitant pain. I also see us about to miss an opportunity
setting out a toolkit that is missing a critical tool. I don't believe the
here should or need to stop us from building the full toolkit, even if the
of toolboxes goes out simply with the right shape cut out, to be filled
Ietf mailing list
Nokia Siemens Networks
Tel: +358 40 527 46 34
Nokia Siemens Networks
Tel: +358 40 527 46 34
Ietf mailing list