Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

[Ray Hunter <[e-mail]>]

> Jouni Korhonen <mailto:[e-mail]>
> 16 May 2013 09:35
>
> I don't disagree about the "dumbness".. However, that is a restriction
> of the
> link itself and buried pretty deep in the architecture. So, if the UE
> receives
> an RA with multiple PIOs a) someone is goofing around or b) the
> network side
> is broken. In that regard, I would still like to keep some text around
> this
> peculiarity in the document. Would it be acceptable to state the fact
> and say
> something along the lines that changing the UE stack implementation to
> meet
> this link requirement is not really needed?
>
> - Jouni
>
> ------------------------------------------------------------------------
IMHO This is symptomatic of the poor relationship between IETF standards
and 3gpp standards. 3gpp has limited something gratuitously that wasn't
limited in the referenced IETF standard. And it didn't need limiting at
standards level anyway: it's a network equipment end implementation
decision. It may be buried in the 3gpp architecture, but it's certainly
NOT buried deep in the IETF architecture.

So you could indeed mention that current versions of 3gpp network
equipment send exactly one PIO, but IMHO the IETF standard should be
kept as intended and unmodified: the TE should accept zero or more PIO
options. Unless it truly breaks something in 3gpp. That way you have
guaranteed interop with 3gpp, without limiting flexibility, or having to
implement unnecessary changes to existing generic running code on a
device that runs IPv6 and also happens to be a 3gpp TE. This is basic
Postel's law.

Futher I cross checked draft-ietf-v6ops-rfc3316bis against rfc6459 (IPv6
in 3rd Generation Partnership Project)
I'm certainly not an expert in this field (just another dumb reader),
but I do like to read consistent and maintainable standards.

AFAICS & IMVHO
Section 2.1 doesn't tell me anything that isn't obvious.
Section 2.2 is mostly covered in rfc6459 section 5.4. Only new material
is regarding [RFC4861], Section 7.3.1, but again that should be pretty
obvious to stack implementers, or could simply be a reference.
Section 2.3 is covered in rfc6459 section 5.2
Section 2.4 is covered in rfc6459 section 5.2
Section 2.5 looks like new information to me and provides actionable advice.
Section 2.6 looks like new information to me but does not tell me any
actionable advice.
Section 2.7 has nothing to do specifically with 3gpp links and could be
better handled elsewhere as a generic IPv6 privacy issue as AFAICS there
are no interop issues specific to 3gpp, and no need to quote 4941
specifically.
Section 2.8 is covered in rfc6459 section 5.2
Section 2.9 is covered in rfc6459 section 5.3
Section 2.10 looks like new information to me, but only contains partial
advice on handling multiple interfaces, so it could do with fleshing
out, or removal [I have no strong opinion either way]
Section 2.11looks like new information regarding handling the MTU option
and looks actionable
Section 3 looks redundant or incomplete.
Section 4 is redundant: an end node may still want to support mobile
IPv6 for e.g. wifi or other purposes: end nodes are not just TE's.

So in summary: I'm seeing an awful lot of unnecessary
duplication/overlap of text with an existing RFC that could be simply
referenced as a whole, and the areas that are providing new information
to me seem to require either more fleshing out, or additional actionable
advice.

I hope you can do something positive with this critique from a dumb reader.


Security considerations
quote "In some cases, users are billed according to the amount of data
they transfer to and from their host.  It is crucial for both the
network and the users that the airtime is used correctly and no extra
charges are applied to users due to misbehaving third parties."

<rant>This is not a technical issue, and the criticism is not directed
at the authors, but I find this outrageous. Why do end users have to pay
for control traffic that doesn't directly benefit them or provide them a
service they've requested? Users don't pay for call set up traffic on
the voice bearers until the call is actually established and answered.
Nor do they pay for maintaining time or other network management
information like establishing network credentials and cell hand off. So
why does the IETF have to put in place a load of technical kludges at
the IPv6 layer to cover something that is fundamentally a billing issue?
If the providers just didn't bill for traffic with a destination address
of the internal network control devices, there'd be no need for any of
this.</rant>

best regards,
RayH