Subject: Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 5 Mar 2022 15:10:21 +0530

Hi John,

We've just posted an update to the draft to address the comments raised and
to clarify the security considerations.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12

Thanks,
Ketan

On Thu, Feb 24, 2022 at 3:42 PM Robert Raszuk <[email-masked]> wrote:

> Hi John,
>
> You have highlighted below a very important point. It was discussed among
> co-authors, but perhaps not sufficiently during the BESS process as the
> issue is really not a BESS WG problem.
>
> In BGP protocol any new service deployment using existing AFI/SAFI is not
> easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
> NLRI attributes. Main reason being is that using capabilities only goes one
> hop. In full mesh it all works perfect, but the moment you put RR in
> between BGP speakers things are getting ugly as capabilities are not
> traversing BGP nodes. /* Even in full mesh mixing transports for the same
> service is a serious challenge for routers when say multihomes sites are
> advertised from different PEs with different transport options */.
>
> Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
> sends a new format of the UPDATE messages. Well as today we also do not
> have a notion of conditional capabilities (only send when received from
> all) so if some of the RR peers do not support it you end up in partial
> service. One can argue that in this case the only deterministic model is to
> push the configuration from the management station and control partial
> deployment of the new service from mgmt layer.
>
> The natural alternative would be to never modify NLRI format once shipped
> by RFC. When needed issue a new SAFI. Yes that is an option (and has always
> been) but it also comes with its own set of issues. New SAFI is really
> great to define for new service/feature etc ... Here however in the context
> of this discussion we are changing transport for existing service.  And
> just like it was the case with MPLS over UDP or  tunnel attribute etc ...
> using a new SAFI would be very hard to deploy as there would need to be
> well defined behaviour of BGP speakers receiving duplicate information for
> the same VPN prefixes or receiving at one time only from single SAFI then a
> bit later from the other one .. Of course one solution is to permit only
> one SAFI for a given service at any given time, but that seems way too
> restrictive too.
>
> So to summarize while I am personally a huge proponent of new SAFI and new
> capabilities to be defines for new service here I do have  some
> reservations. It seems to me that deployment of new transport for VPN
> service should be either network management driven or enabled when all
> participating PEs support it. Enabling it automagically with one hop
> capabilities seems to me like not a good thing as the data being sent in
> the UPDATES is not optional and dropping it means dropping actual routes.
>
> So at the current time the subject draft took a management approach.
>
> Many thx,
> Robert.
>
> On Thu, Feb 24, 2022 at 2:04 AM John Scudder <[email-masked]> wrote:
>
>> Further to this point:
>>
>> > On Feb 18, 2022, at 3:32 PM, John Scudder <[email-masked]> wrote:
>> >
>> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[email-masked]>
>> wrote:
>> >>
>> >>> 2. One area of concern I would have hoped IDR might have looked into
>> is, the
>> >>> document makes a creative use of the MPLS Label field of the NLRI to
>> carry the
>> >>> Function part of the SID. This means the SID is effectively split
>> across the
>> >>> NLRI and the Prefix-SID attribute. What are the potential error modes
>> if the
>> >>> Prefix-SID attribute should be lost from the route, while the NLRI is
>> retained?
>> >>>
>> >>> (An obvious way of addressing this particular concern would be to
>> define a new
>> >>> NLRI type with the desired semantics, instead of creatively
>> repurposing fields
>> >>> within an existing NLRI type contrary to their definitions. Such an
>> NLRI type
>> >>> would, for example, presumably state in its specification that if it
>> was
>> >>> received without an accompanying Prefix-SID attribute, that would
>> constitute an
>> >>> error.)
>> >>>
>> >> KT> This document follows the approach similar as taken for extending
>> MPLS EVPN RFC7432 by RFC8365.
>> >
>> > I take it you’re referring to RFC 8365 §5.1.3 which talks about using
>> the MPLS Label field (or MPLS1 Label field) to carry the VNI in the
>> presence of a BGP Encapsulation Extended Community? Yes, that seems like a
>> pretty close analogue. And given this particular trick is only with
>> VPN-type address families one can also argue that there’s not a risk of
>> affected routes leaking into the big-I Internet, which is the typical
>> associated concern.
>>
>> In a separate reply, the authors of
>> draft-lz-bess-srv6-service-capability-02 pointed out that it provides a
>> critique of bess-srv6-services which is similar to this discuss point. (The
>> authors dropped the IESG from the cc, so I’m following up here instead of
>> to their original note.)
>>
>> On first reading, the critique in
>> draft-lz-bess-srv6-service-capability-02 seems well argued and responsive
>> to my question above about potential error modes. In section 3 of their
>> draft, the authors provide a worked scenario where a VPN route carrying a
>> SRv6 service SID using the Transposition scheme, if received by an
>> MPLS-only PE, could result in misdelivered traffic. At minimum, that seems
>> worth surfacing in the Security Considerations section, since historically
>> we’ve considered misdelivered VPN traffic to be a Bad Thing that could
>> expose confidential information.
>>
>> The authors do acknowledge that bess-srv6-services proposes a mitigation:
>>
>>    To avoid these problems, [I-D.ietf-bess-srv6-services] specifies that
>>    implementations SHOULD provide a mechanism to control advertisement
>>    of SRv6-based BGP service routes on a per neighbor and per service
>>    basis.
>>
>> but they go on to argue that this mitigation isn’t fit for purpose:
>>
>>    The above method may be feasible in small-scale networks, but are not
>>    applicable to large-scale networks.
>>
>>    [etc]
>>
>> It’s not my preference to get into the minutiae of this argument as part
>> of this discuss. However, I’d like to ask: was this consideration something
>> the WG discussed? I looked for discussion of
>> draft-lz-bess-srv6-service-capability in the archives and didn’t find much —
>>
>> - When an earlier version was posted to the list it resulted only in
>> discussion between the original author, Liu Yao, and Eduard Metz, who
>> became co-author, but there wasn’t any discussion I saw of the actual issue
>> that the draft identified, but rather refinement of the mitigation it
>> proposes (which I don’t want to discuss in this note).
>> - There was an agenda slot request for the draft at IETF-111. It was on
>> the agenda in the “if time allows” section. I assume time did NOT allow
>> because I don’t see mention of it in the minutes. (I did find the slides,
>> slides 3 and 4 summarize the critique,
>> https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-srv6-service-capability-00
>> ).
>>
>> But of course, the issue raised might have been discussed by the WG in a
>> different thread, that doesn’t match a search for
>> draft-lz-bess-srv6-service-capability. If so, I’d appreciate a pointer to
>> it.
>>
>> If there wasn’t any discussion in the WG of the authors’ critique, I
>> think it deserves to be discussed a bit as part of this thread. In
>> particular, does the “this is the same as the trick EVPN does in RFC 8365”
>> reply apply equally? Probably it does, although that might boil down to
>> “gosh, we should have caught this when publishing 8365, shouldn’t we?”
>>
>> Even if the outcome of the discussion is that the limitation was
>> discussed by the WG/isn’t a big deal because reasons/maybe it’s a big deal
>> but we’ll fix it in a followup… as I mentioned earlier, covering it in the
>> Security Considerations seems worthwhile.
>>
>> Thanks,
>>
>> —John
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Mar 2022 10:37:41 -0400

Hi Ketan

I reviewed the updated security considerations section and the update looks
good.  As well section 10.3 Data plane considerations and read again the
referenced documents security considerations section of RFC 8402, RFC 8986,
RFC 8754 and RFC 8996.  All looks very good.

One question I had was that if operators only advertises the SRv6 summary
block B:N::/48 to the internet, the summarization route would not contain
the embedded BGP Prefix SID attribute encoding of L2 and L3 Service SID in
the FUNCT field of the SRv6 SID.

If you agree with what I have stated , then that would limit the exposure
drastically related to service SID leakage to the internet.

The security exposure is related to only the inter-as peering lateral,
provider or RS peering and not customer peering as the SRv6 source node
encapsulates customer traffic into payload of outer IPv6 header.  So I
think customer  PE-CE edge peering would not be a security issue.

Also another thought is that within an SRv6 domain as next hop self is used
internally on any inter-as lateral, provider or RS ties which is done on
both ends of the peering between operators, does the SRv6 B:N::/48 underlay
block even need to be advertised externally.  As the BGP overlay is what
holds the internet table and that is all that needs transitivity for
internet route reachability.  That would further reduce the exposure of
data plane service sid encoding in SRv6 SID leaking to the internet.

As far as SRv6 service capabilities draft below, my thoughts are as any
parallel multi transport that exists would only be done within the confines
of a domain within the same operators Administrative domain and not between
providers which would also be limited during a transition from brown field
MPLS or SR-MPLS to a parallel Green field SRv6 transport.  As this use case
is all within the same domain, careful design is on the onus of the
operator as relates to SRv6 to MPLS BGP overlay interoperability for SAFI
128.  So I don’t see this as a major issue for operators as all the careful
considerations will be taken for that interoperability as well as there are
many underlying solutions for SRv6 to MPLS or SR-MPLS interoperability.

This is more of an interoperability issue use case that could be considered
orthogonal to this draft that only exists within an operators network
during migration.

https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02

Kind Regards

Gyan

On Sat, Mar 5, 2022 at 4:40 AM Ketan Talaulikar <[email-masked]>
wrote:

> Hi John,
>
> We've just posted an update to the draft to address the comments raised
> and to clarify the security considerations.
>
>> Imagine RR signals SRv6 Service Capability to the PE. Then this PE
>> happily sends a new format of the UPDATE messages. Well as today we also do
>> not have a notion of conditional capabilities (only send when received from
>> So to summarize while I am personally a huge proponent of new SAFI and
>> new capabilities to be defines for new service here I do have  some
>>> >>> NLRI and the Prefix-SID attribute. What are the potential error
>>> modes if the
>>> >>> Prefix-SID attribute should be lost from the route, while the NLRI
>>> is retained?
>>> >>>
>> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Mar 2022 22:45:16 +0530

Hi Gyan,

Please check inline below for responses.

On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra <[email-masked]> wrote:

>
> Hi Ketan
>
> I reviewed the updated security considerations section and the update
> looks good.  As well section 10.3 Data plane considerations and read again
> the referenced documents security considerations section of RFC 8402, RFC
> 8986, RFC 8754 and RFC 8996.  All looks very good.
>

KT> I agree. However, an even better approach is simply not even
advertising the reachability for the SRv6 summary block on the Internet.
This way, it becomes challenging for someone on the Internet to send
packets to any SRv6 Locators/SIDs belonging to the provider. Also, as
discussed in RFC8986, the allocation of SRv6 Block from the ULA space is
another technique to mitigate this.

> Also another thought is that within an SRv6 domain as next hop self is
> used internally on any inter-as lateral, provider or RS ties which is done
> on both ends of the peering between operators, does the SRv6 B:N::/48
> underlay block even need to be advertised externally.
>

KT> It doesn't and should not be advertised externally.

> As the BGP overlay is what holds the internet table and that is all that
> needs transitivity for internet route reachability.  That would further
> reduce the exposure of data plane service sid encoding in SRv6 SID leaking
> to the internet.
>

KT> Correct.

> This is more of an interoperability issue use case that could be
> considered orthogonal to this draft that only exists within an operators
> network during migration.
>
>

KT> Agree that this topic is orthogonal but is also somewhat complex and we
(WG) need to continue work on this separate from this base document.

Thanks,
Ketan

>>> You have highlighted below a very important point. It was discussed
>>> among co-authors, but perhaps not sufficiently during the BESS process as
>>> the issue is really not a BESS WG problem.
>>>
>>> In BGP protocol any new service deployment using existing AFI/SAFI is
>>> not easy. Especially when you are modifying content of MP_REACH or
>>> MP_UNREACH NLRI attributes. Main reason being is that using capabilities
>>> only goes one hop. In full mesh it all works perfect, but the moment you
>>> put RR in between BGP speakers things are getting ugly as capabilities are
>>> not traversing BGP nodes. /* Even in full mesh mixing transports for the
>>> same service is a serious challenge for routers when say multihomes sites
>>> are advertised from different PEs with different transport options */.
>>>
>>> The natural alternative would be to never modify NLRI format once
>>> shipped by RFC. When needed issue a new SAFI. Yes that is an option (and
>>> has always been) but it also comes with its own set of issues. New SAFI is
>>> really great to define for new service/feature etc ... Here however in the
>>> context of this discussion we are changing transport for existing service.
>>> And just like it was the case with MPLS over UDP or  tunnel attribute etc
>>> ... using a new SAFI would be very hard to deploy as there would need to be
>>>> >>> 2. One area of concern I would have hoped IDR might have looked
>>>> into is, the
>>>> >>> document makes a creative use of the MPLS Label field of the NLRI
>>>> to carry the
>>>> >>> would, for example, presumably state in its specification that if
>>>> it was
>>>> >> KT> This document follows the approach similar as taken for
>>>> extending MPLS EVPN RFC7432 by RFC8365.
>>>> >
>>>> It’s not my preference to get into the minutiae of this argument as
>>>> part of this discuss. However, I’d like to ask: was this consideration
>>>> something the WG discussed? I looked for discussion of
>>>> But of course, the issue raised might have been discussed by the WG in
>>>> a different thread, that doesn’t match a search for

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Mar 2022 14:53:43 -0400

Hi Ketan

Responses in-line

> another technique to mitigate this.
    Gyan> Can we add that in the considerations section as I think that
will help with John and Warrens security concerns with sid leakage.

> KT> It doesn't and should not be advertised externally.

   Gyan> Excellent.  I think explicit verbiage to block externally would be
good.

> KT> Agree that this topic is orthogonal but is also somewhat complex and
> we (WG) need to continue work on this separate from this base document.
>

   Gyan> Understood.

Thanks

>>>>> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <
>>>>> [email-masked]> wrote:
>>>>> >>
>>>>> >>> within an existing NLRI type contrary to their definitions. Such
>>>>> an NLRI type
>>>>> > I take it you’re referring to RFC 8365 §5.1.3 which talks about
>>>>> using the MPLS Label field (or MPLS1 Label field) to carry the VNI in the
>>>>> - There was an agenda slot request for the draft at IETF-111. It was
>>>>> on the agenda in the “if time allows” section. I assume time did NOT allow

*Gyan Mishra*

*M 301 502-1347*

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 19:03:20 +0000

Hi Authors,

I’m not sure if this point was considered and rejected (in which case let’s close it out in email please), or (more likely) just dropped?

> On Feb 18, 2022, at 4:48 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi John,
> 
>> Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI registry. Shouldn’t this be renamed? I mean, I guess it should have been renamed as of RFC 8365, but better late than never. I’m not sure quite what the name should become, but “MPLS-labeled” is manifestly wrong. Even “labeled” is wrong since the thing you’re stuffing in there isn’t a label. Since you’re the last one to touch it :-) if we can agree a better name for the SAFI I think it would be appropriate to add that to your IANA Considerations.
>> 
> My suggestion would be: "VPN address & context"  or "Context & VPN address"
> 
> Thx,
> R.

I like either of Robert’s suggestions. This would go some small way towards addressing my concern #2.

Suggested text for the IANA Considerations section:

9.X Subsequent Address Family Identifiers (SAFI) Parameters Registry

IANA maintains a registry called Subsequent Address Family Identifiers (SAFI) Parameters. In that registry, value 128 has the description "MPLS-labeled VPN address”, references [RFC4364][RFC8277]. This specification, as well as [RFC 8365] before it, changes the semantics of SAFI 128 such that it can carry values other than an MPLS label. Therefore, IANA is requested to update the description of value 128 to be "VPN address & context” and to add [RFC 8365] and [this document] as references.

Regards,

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 00:57:43 +0530

Hi John,

This point was discussed amongst some of the authors. We were not sure if
we had got all the references to the specs that do this kind of handling
for "embedded label". RFC9012 came up as another possible reference.

I was wondering if we could go about this change in a separate (AD
sponsored?) draft so we don't miss anything and also get more inputs from
the WGs involved? It is not a functional but an IANA update.

I can volunteer to put together a short draft for this with your guidance.

Please let me know your thoughts.

Thanks,
Ketan

On Wed, 23 Mar, 2022, 12:33 am John Scudder, <[email-masked]> wrote:

> Hi Authors,
>
> I’m not sure if this point was considered and rejected (in which case
> let’s close it out in email please), or (more likely) just dropped?
>
> >> Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA
> SAFI registry. Shouldn’t this be renamed? I mean, I guess it should have
> been renamed as of RFC 8365, but better late than never. I’m not sure quite
> what the name should become, but “MPLS-labeled” is manifestly wrong. Even
> “labeled” is wrong since the thing you’re stuffing in there isn’t a label.
> Since you’re the last one to touch it :-) if we can agree a better name for
> the SAFI I think it would be appropriate to add that to your IANA
> Considerations.
> >>
> IANA maintains a registry called Subsequent Address Family Identifiers
> (SAFI) Parameters. In that registry, value 128 has the description
> "MPLS-labeled VPN address”, references [RFC4364][RFC8277]. This
> specification, as well as [RFC 8365] before it, changes the semantics of
> SAFI 128 such that it can carry values other than an MPLS label. Therefore,
> IANA is requested to update the description of value 128 to be "VPN address
> & context” and to add [RFC 8365] and [this document] as references.
>
> Regards,
>
> —John

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 20:17:34 +0000

Yes, you’re right that 9012 is another possible ref.

Regarding the option of doing it in the current spec —

- I hear you that you’re not certain you’d be capturing every relevant reference, however I think this is a case of “best is the enemy of good”. Listing the known references would be an improvement over the current state of affairs, likewise updating the description.
- There is nothing preventing a later doc from updating the registry again, if that’s deemed necessary. Registries are updated all the time. So, we wouldn’t be foreclosing any options or doing anything irreversible.
- Getting WG input (such as would come from a full last call) is certainly important for many things, but you’ve just pointed out yourself that this isn’t a functional change, so I think it’s unlikely that any harm would ensue from not invoking maximum process. 

I had a look at BCP 26/RFC 8216 and this approach seems consistent with the guidance there. Indeed, strictly speaking it would be inappropriate NOT to add [this document] as a reference in the registry, at minimum — so the only question then becomes, whether to update the description and add the other references at the same time.

Bottom line, I continue to think it’s appropriate to do it in the current spec, and more expedient. Seems like all upside, no downside, very good bang-for-the-buck. 

Here’s what (per my reading of BCP 26 §7) the bare-bones update would look like:

IANA is requested to add this document as a reference for value 128 in the Subsequent Address Family Identifiers (SAFI) Parameters registry.

That would then leave the other work for a later draft, as you suggest. I’m only providing the above for clarity, it’s not my recommendation, the earlier version is.

—John

> On Mar 22, 2022, at 3:27 PM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 
> Hi John,
> 
> This point was discussed amongst some of the authors. We were not sure if we had got all the references to the specs that do this kind of handling for "embedded label". RFC9012 came up as another possible reference.
> 
> I was wondering if we could go about this change in a separate (AD sponsored?) draft so we don't miss anything and also get more inputs from the WGs involved? It is not a functional but an IANA update.
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 02:09:05 +0530

Hi John,

Thanks for those details. I agree that there shouldn't be an issue with
your bare-bones proposal. An update with this text change and [1] has just
been posted:

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-14

Please let us know if this addresses your concerns.

Thanks,
Ketan

[1] This is the clarification requested by Joel as discussed on the WG
mailer :
https://mailarchive.ietf.org/arch/msg/bess/smMPKgPXxnOQ1rzWRf0IoKhSTfU/

On Wed, Mar 23, 2022 at 1:47 AM John Scudder <[email-masked]> wrote:

> - I hear you that you’re not certain you’d be capturing every relevant
> reference, however I think this is a case of “best is the enemy of good”.
> Listing the known references would be an improvement over the current state
> of affairs, likewise updating the description.
> - There is nothing preventing a later doc from updating the registry
> again, if that’s deemed necessary. Registries are updated all the time. So,
> we wouldn’t be foreclosing any options or doing anything irreversible.
> - Getting WG input (such as would come from a full last call) is certainly
> important for many things, but you’ve just pointed out yourself that this
> isn’t a functional change, so I think it’s unlikely that any harm would
> ensue from not invoking maximum process.
>
> I had a look at BCP 26/RFC 8216 and this approach seems consistent with
> the guidance there. Indeed, strictly speaking it would be inappropriate NOT
> to add [this document] as a reference in the registry, at minimum — so the
> only question then becomes, whether to update the description and add the
> other references at the same time.
>
> Bottom line, I continue to think it’s appropriate to do it in the current
> spec, and more expedient. Seems like all upside, no downside, very good
> bang-for-the-buck.
>
> IANA is requested to add this document as a reference for value 128 in the
> Subsequent Address Family Identifiers (SAFI) Parameters registry.
>
> That would then leave the other work for a later draft, as you suggest.
> I’m only providing the above for clarity, it’s not my recommendation, the
> earlier version is.
>
> —John
>
> > This point was discussed amongst some of the authors. We were not sure
> if we had got all the references to the specs that do this kind of handling

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 20:48:52 +0000

On Mar 22, 2022, at 4:39 PM, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:

While I’m disappointed you’ve opted not to “leave the campsite cleaner than you found it”, I can live with it, assuming we’ll then take up the promised follow-on document to make the additional changes that we discussed.

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 02:27:26 +0530

Hi John,

I'll work on the proposal right after this IETF and share it with you
before posting.

Most likely it goes trivially as you suggested and in the process also
secure wider WG consensus for the naming change(s).

Thanks,
Ketan

On Wed, 23 Mar, 2022, 2:18 am John Scudder, <[email-masked]> wrote:

> On Mar 22, 2022, at 4:39 PM, Ketan Talaulikar <[email-masked]>
> wrote:
>
> While I’m disappointed you’ve opted not to “leave the campsite cleaner
> than you found it”, I can live with it, assuming we’ll then take up the
> promised follow-on document to make the additional changes that we
> discussed.
>
> —John
>

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 21:07:45 +0000

Got it, thanks.

And see my email that crossed yours on the wire, regarding where to target it, etc.

—John

On Mar 22, 2022, at 4:57 PM, Ketan Talaulikar <[email-masked]> wrote:

Hi John,

I'll work on the proposal right after this IETF and share it with you before posting.

Most likely it goes trivially as you suggested and in the process also secure wider WG consensus for the naming change(s).

Thanks,
Ketan

On Wed, 23 Mar, 2022, 2:18 am John Scudder, <[email-masked]<mailto:[email-masked]>> wrote:
On Mar 22, 2022, at 4:39 PM, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:

—John