Subject: Re: [NSIS] QoS NSLP v. "13-pre1"

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 6 Dec 2006 12:09:25 +0200 (EET)

Dear all,

I sent the following request for feedback two weeks ago. No comments have 
been raised. I will wait until this Friday, then submit the draft.

Jukka

On Tue, 21 Nov 2006, Jukka MJ Manner wrote:

> 
> Hi all,
> 
> I have done all the edits I had in my list to the QoS NSLP spec, the main 
> points are in recent thread with Roland. From the url below you can find 
> the current draft v. "13-pre1" and a diff to v. 12.
> 
> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/
> 
> A direct link to the diff:
> 
> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/draft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.html
> 
> 
> I would appreciate comments on the changes I did (what is wrong, what I 
> missed, etc.).
> 
> 
> I still have one problem with the spec, namely the way the NSLP suggests 
> to handle mobility and path changes. I think we need to review that 
> statement, because it seems like a "hack" (playing with the RSN value), 
> and not really useful. And the interactions with GIST look partly wrong. 
> The folks working on the mobility draft (me included) could comment. The 
> section I'm talking about is 3.2.10, especially 3.2.10.2, in the v.12 
> draft.
> 
> BR,
> Jukka
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 06 Dec 2006 14:47:27 +0000

Hi,

A few comments (complete with suggested changes).

Jukka: I sent you the first couple directly, and then decided it was 
probably a good idea to send them all to the list.

A minor rewording suggestion in 4.8. I don't think the problem is about 
finding a P-QNE, it is more fundamentally (at a GIST level) about 
finding a next upstream peer (since there could be more than one hop to 
the P-QNE).

Current (13-pre1) text:
-- 
    For incoming data flows, the end host is the QNI, and it sends a
    RESERVE towards the data sender with the PROXY scope flag set. Here
    the end host sets the MRI so that it indicates the end host as the
    receiver of the data, and sets the D-flag.

    Now GIST will seek to route the RESERVE using reverse routing. If
    there is only one P-QNE in the domain, it is trivial for GIST to
    forward the RESERVE to the P-QNE. If there are more than one P-QNEs,
    GIST may be able to find the correct QNE for the reserve route, but
    may also reply with an error indicating destination unreachable,
    e.g., if there are multiple inbound routes and the data flow may
    arrive from either route - GIST does not send the RESERVE to multiple
    P-QNEs. See the GIST spec [I-D.ietf-nsis-ntlp] for more information
    on GIST's ability to do reverse routing.
-- 

Proposed text:
-- 
For incoming data flows, the end host is the QNI, and it sends a RESERVE 
towards the data sender with the PROXY scope flag set. Here the end host 
sets the MRI so that it indicates the end host as the receiver of the 
data, and sets the D-flag.

GIST is able to send messages towards the data sender if there is 
existing message routing state or it is able to use the Upstream Q-mode 
Encapsulation. In some cases GIST will be unable to determine the 
appropriate next hop for the message, and so will indicate a failure to 
deliver it (by sending an error message). This may occur, for example, 
if GIST attempts to determine an upstream next hop and there are 
multiple possible inbound routes that could be used.
-- 

Another minor one on 5.1.1:
13-pre1 text:
--
    The ACK flag is usefull when a QNE wants to make sure the messages
    received by the downstream QNE are truly processed, even when GIST
    continues to work. This is usefull for faster dead peer diagnostics
    on the NSLP layer. Reliable transmission of messages between two QoS
    NSLP peer should be handled by GIST, not the NSLP by itself.
--
I'm not sure what "even when GIST continues to work" means.
(and 'usefull' has only one 'l')

Would the following be clearer?
--
The ACK flag is useful when a QNE wants to make sure the messages 
received by the downstream QNE are truly processed by the QoS NSLP, not 
just delivered by GIST. This is useful for faster dead peer diagnostics 
on the NSLP layer. Reliable transmission of messages between two QoS 
NSLP peer should be handled by GIST, not the NSLP by itself.
--
5.1.2.1 BNF says:
    RESERVE = COMMON_HEADER
              RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ]
              [ SESSION_ID_LIST ] [ RSN_LIST ]
              [ [ PACKET_CLASSIFIER ] QSPEC ]

(and similarly for RESPONSE)

This says that you can have an RSN_LIST with no SESSION_ID_LIST. That 
doesn't sound right to me. Is the following correct:

    RESERVE = COMMON_HEADER
              RSN [ RII ] [ REFRESH_PERIOD ] [ *BOUND_SESSION_ID ]
              [ SESSION_ID_LIST [ RSN_LIST ] ]
              [ [ PACKET_CLASSIFIER ] QSPEC ]

and for RESPONSE:
  RESPONSE = COMMON_HEADER
               [ RII / RSN ] INFO_SPEC [ SESSION_ID_LIST [ RSN_LIST ] ]
               [ QSPEC ]

i.e. if you include a SESSION_ID_LIST you can also include an RSN_LIST

Could the object formats in 5.1.3.7/5.1.3.8 also be made a bit clearer 
(more detailed), i.e.:

current 13-pre1:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                          Session IDs                          +
    |                                                               |
    +                                                               +
    |                                                               |
    /                                                               /
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

suggestion:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                         Session ID 1                          +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                         Session ID n                          +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(following pattern in some of the GIST formats)

Similarly in RSN_LIST:
13-pre1:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /                  Reservation Sequence Numbers                 /
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I suspect you need the Epoch Identifier (I've only thought about this 
very briefly), not just the 'raw' RSN (the term 'Reservation Sequence 
Numbers' is possibly a little vague here). However, since the Epoch 
Identifier is for the entire QNE, not per-peer, so you only need one.

Suggestion:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Epoch Identifier                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Reservation Sequence Number 1 (RSN1)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Reservation Sequence Number n (RSNn)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In a number of places there are some "RNS" typos that should be "RSN"

5.3.6: "uknown" -> "unknown"
5.3.6: "sessiond" -> "Session ID"

regards,
Andrew

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 6 Dec 2006 17:49:05 +0200 (EET)

Thanks, Andrew, will change all.

Jukka

On Wed, 6 Dec 2006, Andrew McDonald wrote:

> Jukka: I sent you the first couple directly, and then decided it was probably
> a good idea to send them all to the list.
> 
> finding a P-QNE, it is more fundamentally (at a GIST level) about finding a
> next upstream peer (since there could be more than one hop to the P-QNE).
> 
> Current (13-pre1) text:
>

---

From: Bernd Schloer <[email-masked]>
Date: Fri, 8 Dec 2006 18:49:07 +0100 (MET)

Hi Jukka,

to my knowledge the case of section 3.2.10.2 is not covered in section 5.4.1,
where the Message Processing Rules of RESERVE Messages are explained. A sends a RESERVE
to C while on Node A and C still reservation state for this Session ID is installed. The
FlowID is unchanged, the MRI is unchanged, the REPLACE-Flag is not set, the Session
ID is the same and the SII-Handle is unchanged for C.

However there's a case for sessions with the REPLACE flag = 0 (does this mean a received
RESERVE message where the REPLACE flag in the Common Header is not set?) where it is
assumed that the QoS model includes directions to deal with resource sharing. Adding a
reservation or taking the the maximum of two? Or more complex mathematical operations?
What does this mean?

But back to the rerouting problem. When A attempts to tear down the reservation on the old
path by specifying explicit routing to the old peer with the related SII-Handle, nothing
would happen, when link (1) still fails.

Bernd

---

From: Bernd Schloer <[email-masked]>
Date: Fri, 8 Dec 2006 22:17:09 +0100 (MET)

Hi Jukka,

the Summary Refresh and Teardown concept doesn't convince me. It might be true that
the number of individual messages gets reduced. The operating overhead increases.
In an error case when the lists are only partly processed, the remaining sessions
of these lists don't get refreshed/torn down.

Bernd

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 9 Dec 2006 16:49:50 +0100 (MET)

Hi Jukka,

the initial route A-B-C uses links (1) and (3). After link (1) fails, the path is
rerouted using links (2) and (3).

              (1)
            /-----\                       |x| = QoS NSLP aware
          +-+     /-\ (3) +-+             +-+
      ----|A|     |B|-----|C|----
          +-+     \-/     +-+             /-\
            \-----/                       |x| = QoS NSLP unaware
              (2)

section 3.2.10 says

    When the QoS NSLP is aware of the route change, it needs to set up
    the reservation on the new path. This is done by sending a new
    RESERVE message. If the next QNE is, in fact, unchanged then this
    will be used to refresh/update the existing reservation. Otherwise it
    will lead to the reservation being installed on the new path.

section 5.3.1.says

    If the RSN is greater than the current stored value, the current reservation
    MUST be modified appropriately (provided that admission control and policy
    control succeed), and the stored RSN value updated to that for the new
    reservation.

According to section 3.2.10 sending a full RESERVE including a QSPEC and the next
peer is unchanged the reservation will be updated/refreshed. However section 5.3.1
talks not about refreshing/updating, it says the current reservation must be modified
appropriately. What is the meaning of "appropriately" here? What happens to the current
reservation?

When A sends a full RESERVE with set SCOPING-Flag including RII and QSPEC object,
and if the RESERVE will be treated as an updating, refreshing RESERVE, the RESPONSE
will contain an INFO object with Success, Reservation succesful. In case of new
installed state, the RESPONSE contains also an INFO object with Success, Reservation
succesful.

It would be helpful to make a difference between Reservation succesful and Refresh
succesful. In case of Refresh succesful, there's no need to tear down the reservation
on the old path. In case of Reservation succesful it might be. When link (1) still
fails the teardown message would timeout in this example.

What do you think?

Bernd

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 9 Dec 2006 20:32:51 +0100 (MET)

section 5.4.1 says

    As discussed in Section 5.2.5.2, to avoid incorrect removal of state
    after a rerouting event, a node receiving a RESERVE message with the
    TEAR flag set which does not come from the current peer QNE,
    identified by its SII, MUST be ignored and MUST NOT be forwarded.

The SII-Handle is generated by GIST and points to the GIST next hop and
to the local interface. In this case for C the current peer QNE is A,
but the SII-Handle points to B. Any existing reservation can neither
over (1), nor over (2) be removed.

In case a router just rebooted, it has no current peer QNE, but should
forward the tearing RESERVE, as discussed here
http://www1.ietf.org/mail-archive/web/nsis/current/msg06697.html
Existing reservations will not be removed further along the path.

Bernd

Bernd Schloer wrote:
>> I sent the following request for feedback two weeks ago. No comments 
>> have been raised. I will wait until this Friday, then submit the draft.
>>
>> Jukka
>>
>>> I have done all the edits I had in my list to the QoS NSLP spec, the 
>>> main points are in recent thread with Roland. From the url below you 
>>> can find the current draft v. "13-pre1" and a diff to v. 12.
>>>
>>> I would appreciate comments on the changes I did (what is wrong, what 
>>> I missed, etc.).
>>>
>>>
>>> I still have one problem with the spec, namely the way the NSLP 
>>> suggests to handle mobility and path changes. I think we need to 
>>> review that statement, because it seems like a "hack" (playing with 
>>> the RSN value), and not really useful. And the interactions with GIST 
>>> look partly wrong. The folks working on the mobility draft (me 
>>> included) could comment. The section I'm talking about is 3.2.10, 
>>> especially 3.2.10.2, in the v.12 draft.
>>>
>>> BR,
>>> Jukka
>>>

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 10 Dec 2006 20:45:02 +0200 (EET)

This was discussed with a number of people in SD and thought to be a good 
idea. I'd like to hear other people say this is not needed, otherwise I 
will keep the spec as it is.

What is this error case where the list is only partly processed? Don't 
understand.

Jukka

On Fri, 8 Dec 2006, Bernd Schloer wrote:

> > >I still have one problem with the spec, namely the way the NSLP suggests to
> > >handle mobility and path changes. I think we need to review that statement,
> > >because it seems like a "hack" (playing with the RSN value), and not really
> > >useful. And the interactions with GIST look partly wrong. The folks working
> > >on the mobility draft (me included) could comment. The section I'm talking
> > >about is 3.2.10, especially 3.2.10.2, in the v.12 draft.
> > >
> > >BR,
> > >Jukka
> > >

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 10 Dec 2006 20:50:50 +0200 (EET)

Hi,

I think the general design decision in any protocol is that if you don't 
understand a message, you should drop it. In the case of the QoS NSLP, 
dropping the message is the right thing to do; the reservation will be 
torn down eventually due to the refresh timeout.

Jukka

On Sat, 9 Dec 2006, Bernd Schloer wrote:

> > > > main points are in recent thread with Roland. From the url below you can
> > > > find the current draft v. "13-pre1" and a diff to v. 12.
> > > >

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 10 Dec 2006 20:52:25 +0200 (EET)

Hi,

I'm a bit lost in what you are talking about.

Andrew, Section 3.2.10 is basically your design, any comment?

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 10 Dec 2006 20:53:02 +0200 (EET)

Andy, since this is your design, any comments?

Jukka

---

From: Takako Sanda <[email-masked]>
Date: Wed, 13 Dec 2006 15:05:56 +0900

Hi Jukka and all,

I would like to clarify about tearing down operation.

In section 3.2.11 (Rerouting), 5th paragraph, it is said,
   "After the reservation on the new path is set up, the branching node
   may want to tear down the reservation on the old path (sooner than
   would result from normal soft-state time-out)."

This means that the CRN will initiate the TEAR on the old path.

At Munich Interim, It was discussed that tearing down from intermediate
node needs to be avoided because of session ownership issue. But I
cannot find any conclusion of this discussion.
http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html

Do we have any decision for "tearing down from intermediate node"?

cheers,
Takako

On Wed, 06 Dec 2006 12:09:25 +0200 (EET)

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 13 Dec 2006 11:17:39 +0200 (EET)

Hi all,

If you look at how the NSIS protocols work, there is no way a node can
make sure a tear-down was intiated by the QNI. A QNE receives a
teardown from its upstream peer, but it can't tell whether that peer
initiated the tear down in the first place, or the QNI.

If I would do a "mobility enhanced QoS NSLP", I would tear down at the 
cross-over router the unnecessary reservation. Of course the spec can say 
"don't do it", but a QNE can not really confirm it isn't being done. And 
the QNI or the QNR can't see that either.

The QoS NSLP spec could say "only the QNI SHOULD (or MAY) be able to 
initiate a tear down", and thus leave the option open for a QNE to also do 
it.

Or we could make a new INFO_SPEC code for "reservation not need" which is 
a hint sent by the cross-over router to inform downstream QNEs on the old 
path that the MN has moved away. It is then up to each QNE to decide 
whether to remove the resources and state, or not.

Jukka

---

From: Hong Cheng <[email-masked]>
Date: Thu, 14 Dec 2006 12:10:20 +0800

Hi Jukka,

I would agree that the cross-over router should be left capable of 
tearing down the unneeded reservations. Please see some comments inline 
below:

cheers

Cheng Hong

> initiate a tear down", and thus leave the option open for a QNE to also do 

[Cheng] Agree. This should be left open. And I think the quoted text in 
current QoS NSLP draft is reflecting this point.

> whether to remove the resources and state, or not.

[Cheng] This option might lead to some problem though, since it could 
leave the QNEs on the path unsynchronized should they decide to do 
different things in response to the INFO_SPEC.

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 20 Dec 2006 15:19:20 +0000

Hi Jukka, Bernd,

> Andy, since this is your design, any comments?

Not sure I'd claim responsibility for all of this (though I undoubtably 
wrote some of it).

>>            /-----\                       |x| = QoS NSLP aware

"Appropriately" means "as instructed by the QSpec in the message". If 
that QSpec is unchanged (as in the section 3.2.10 case) then the only 
effect is to refresh the current reservation.

>> fails the teardown message would timeout in this example.

It doesn't sound unreasonable.

Would the intention be to mandate a different behaviour? Or, should it 
be documented as a 'hint' (i.e. you might not want to do the tear if you 
get the 'successful refresh' response)? Or is no further information 
needed on how it might affect your processing?

Andrew

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 20 Dec 2006 15:43:24 +0000

>> ID is the same and the SII-Handle is unchanged for C.

It is covered in section 5.2.5.2. I can't see any obvious conflicts 
between 5.4.1 and 5.2.5.2. Are there any specific clarifying words that 
you think are required?

>> reservation or taking the the maximum of two? Or more complex mathematical

Hmm. I would not interpret REPLACE as involving any mathematical 
operation. My understanding was that it more simply means "in the case 
where there are two available paths, should there be a reservation on both".

>> would happen, when link (1) still fails.

(I assume you are referring to figure 6)

Yes, I think that is the point.

The core of the discussion in 3.2.10.2 is:
- sometimes A may think that a route change has happened when it hasn't
- when that happens we don't want A to accidently tear down the state

Or am I missing something in your question?

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 21 Dec 2006 15:00:57 +0100

Hi Bernd 

I agree with Jukka!

Best regards,
Georgios
 
> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: zondag 10 december 2006 19:51
> To: Bernd Schloer
> Cc: [email-masked]
> Subject: Re: [NSIS] QoS NSLP v. "13-pre1"
> 
> 
> Hi,
> 
> I think the general design decision in any protocol is that 
> if you don't understand a message, you should drop it. In the 
> case of the QoS NSLP, dropping the message is the right thing 
> to do; the reservation will be torn down eventually due to 
> the refresh timeout.
> 
> Jukka
> 
> > The SII-Handle is generated by GIST and points to the GIST next hop 
> > and to the local interface. In this case for C the current 
> peer QNE is 
> > A, but the SII-Handle points to B. Any existing reservation can 
> > neither over (1), nor over (2) be removed.
> > 
> > > the initial route A-B-C uses links (1) and (3). After link (1) 
> > > fails, the path is rerouted using links (2) and (3).
> > > 
> > > 
> > >              (1)
> > >    If the RSN is greater than the current stored value, 
> the current 
> > > reservation
> > >    MUST be modified appropriately (provided that 
> admission control 
> > > and policy
> > > According to section 3.2.10 sending a full RESERVE 
> including a QSPEC 
> > > and the next peer is unchanged the reservation will be 
> > > updated/refreshed. However section
> > > 5.3.1
> > > talks not about refreshing/updating, it says the current 
> reservation 
> > > must be modified appropriately. What is the meaning of 
> > > "appropriately" here? What happens to the current reservation?
> > > 
> > > When A sends a full RESERVE with set SCOPING-Flag 
> including RII and 
> > > QSPEC object, and if the RESERVE will be treated as an updating, 
> > > refreshing RESERVE, the RESPONSE will contain an INFO object with 
> > > Success, Reservation succesful. In case of new installed 
> state, the 
> > > RESPONSE contains also an INFO object with Success, Reservation 
> > > succesful.
> > > 
> > > It would be helpful to make a difference between Reservation 
> > > succesful and Refresh succesful. In case of Refresh succesful, 
> > > there's no need to tear down the reservation on the old path. In 
> > > case of Reservation succesful it might be. When link (1) 
> still fails 
> > > the teardown message would timeout in this example.
> > > 
> > > What do you think?
> > > 
> > > Bernd
> > > 
> > > 
> > > 
> > > 
> > > Jukka MJ Manner wrote:
> > > 
> > > > Dear all,
> > > >
> > > > I sent the following request for feedback two weeks ago. No 
> > > > comments have been raised. I will wait until this 
> Friday, then submit the draft.
> > > >
> > > > Jukka
> > > >
> > > > > I have done all the edits I had in my list to the QoS 
> NSLP spec, 
> > > > > the main points are in recent thread with Roland. 
> From the url 
> > > > > below you can find the current draft v. "13-pre1" and 
> a diff to v. 12.
> > > > >
> > > > > I would appreciate comments on the changes I did 
> (what is wrong, 
> > > > > what I missed, etc.).
> > > > >
> > > > >
> > > > > review that statement, because it seems like a "hack" 
> (playing 
> > > > > with the RSN value), and not really useful. And the 
> interactions with GIST look partly wrong.
> > > > > The folks working on the mobility draft (me included) could 
> > > > > comment. The section I'm talking about is 3.2.10, especially 
> > > > > 3.2.10.2, in the v.12 draft.
> > > > >
> > > > > BR,
> > > > > Jukka
> > > > >