Re: [bess] draft-rosen-mpls-rfc3107bis

[bruno.decraene]

Sorry for the late answer and for breaking the email thread. (my laptop hard 
drive failed during the IETF week).

Please see 2 comments inline [Bruno]

And as already expressed, I support the adoption of this document.



From: Eric C Rosen [mailto:ero...@juniper.net]

Right now, we're arguing about which of the following two strategies is

more likely to cause a problem:



1. In the first strategy, 3107bis requires the S bit to be set when

there is a single label.  This will allow 3107bis to interoperate with

3107 implementations of "multiple labels", but it will not allow 3107bis

to interoperate with (buggy) 3107 implementations that send a single

label, but don't set the S bit.



2. In the second strategy, 3107bis assumes, in the absence of the

Capability, that there is only a single label, and doesn't bother to

check the S bit.  This will allow 3107bis to interoperate with (buggy)

implementations that send a single label but fail to set the S bit; it

will not allow 3107bis to interoperate with (non-buggy) 3107

implementations of multiple labels.



My argument is that the second strategy is better because it will be

less disruptive.  This is based on my belief that the "day 1" bugs do

exist, and that the "multiple labels" feature has yet to be deployed.



Your argument seems to be that the first strategy is better because (a)

it only causes disruption if the 3107 implementation has a bug, in which

case the bug can be fixed, and (b) if the second strategy is used, a

3107-compliant implementation of multiple labels will fail to

interoperate with a 3107bis-compliant implementation of multiple labels,

and both implementors will claim compliance.



[Bruno] Thank you for this good and fair summary.

I would add: (c) a 3107-compliant implementation of multiple labels sending one 
route with multiple labels to a 3107bis-compliant implementation of a single 
label, will trigger the shutdown of the BGP sessions and hence the removal of 
all labelled routes and most likely all routes from all AFI/SAFI sharing this 
BGP session. This is very disruptive. And both implementors will claim 
compliance.





There may be a third strategy: second strategy, plus when a BGP error is found 
when parsing the NLRI, search for the S bit in order to identify the IP prefix 
and treat it as withdraw. (rather than kill the BGP session)



To be on the extra safe side, I'd prefer the third strategy, on the basis that 
you never know what you can receive (cf the BGP attribute 99 incident, which 
nobody asked for/expected), plus the 3107 speaker sending multiple labels IS 
compliant.

If you don't think that this is feasible/reasonable, I'm fine with the second 
strategy.





I think your argument is reasonable, the question is really just which

strategy will cause less disruption.



[Bruno] In either case, it seems like the draft will need to document the issue 
and warn the network operator about it.



Do other members of the WGs have opinions about this?

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-rosen-mpls-rfc3107bis

[Eric C Rosen]

On 4/5/2016 8:05 AM, Robert Raszuk wrote:
Wouldn't it be more flexible to simply define new attribute to carry  > the stack within any SAFI as an opaque to BGP data ? That way one 

can > easily use it in unicast SAFI or even in FlowSpec.

That can be done with the Tunnel Encapsulation attribute.  Look at, for 
example, at draft-previdi-idr-segment-routing-te-policy (though I think 
that document still needs quite a bit of work).



If as it turns out if the primary motivation for 3107bis is to  > distribute 
label stack for segment routing


3107bis fixes a number of problems in 3107, and it also specifies how to 
use the "multiple labels" feature without tickling known bugs in 
existing deployments.   One could argue about whether this is the best 
tool for various segment routing applications, but that's outside the 
scope of the draft.  And there are use cases that have nothing to do 
with segment routing; see, e.g., the discussion of context labels in 
section 4.









___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-rosen-mpls-rfc3107bis

[bruno.decraene]

> From: Eric C Rosen [mailto:ero...@juniper.net]
> Sent: Friday, April 01, 2016 1:44 PM
> 
> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
> >> I'm quite sure you have deployed  implementations, from several
> >> prominent vendors, that will not properly handle this case.
> > I'm waiting for this/these implementation(s) to make a public statement
> in this thread / IETF WGs. Then we can discuss whether the issue comes
> from RFCF3107 or from the implementation.
> > If none make a public statement, we should assume that all
> implementations are capable of receiving multiple labels, as per RFC 3107.
> I strongly disagree with this.  We should not ignore the facts just
> because you don't like the way the facts were gathered.
> 
> A better approach would be to have operators state whether they have any
> deployments in which the "multiple labels" feature is used in a
> multi-vendor environment.  It is very useful when working on a "bis"
> draft to determine which features have been proven to work in a
> multi-vendor environment and which have not.

Asking operators or vendors is equally fine for me.
My issue is how do we prove that _nobody_ is using it? Proving the negative is 
hard, and silence is not part of the proof. To prove the negative, we would 
need explicit statement from everyone, which looks impossible.
 
> > Any non-compliant implementation may create interoperability issues and
> unpredictable results.
> >  From an IETF standpoint, the question is whether a RFC 3107
> implementation would create interoperability issues, up to shutting down
> the BGP session.
> 
> There are deployed 3107 implementations which always assume that the
> NLRI contains a single label.  If you tried to interwork these with 3107
> implementations that send multiple labels , you will experience the kind
> of disruption. 

Agreed. But between 2 3107 speakers, we can determine which implementation has 
a bug. Whereas between a 3107 speaker and 3107bis speaker, both implementations 
may be compliant, but still the BGP session would go done.

> 3107bis tries to allow the use of multiple labels while
> preventing this sort of disruption from occurring.

Agreed. I support this.
 
> > If you mean that some non-compliant implementation do not work, well
> let's fix them.
> 
> The situation is that there is a commonly deployed "bug" in old
> implementations, but it is not seen because the bug is in a feature that
> no one has been using.  If new implementations use that feature, the bug
> will be seen, and network disruption will occur. One could say "fix all
> the old implementations", but it seems wiser to have new implementations
> avoid tickling the bug.   The Capability is not proposed  for the
> purpose of helping the vendors, it's there to help the operators.

I support the capability.
 
> I'm not sure why you think there would be BGP session drops due to
> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
> implementation, I think the 3107bis implementation would do
> "treat-as-withdraw" rather than "drop the session".

"treat-as-withdraw" would be fine for me. But this requires the 3107bis 
implementation to be able to parse the stack of (multiple) labels, in order to 
identify the IP prefix and treat it as withdraw. However, by hypothesis, this 
speaker is not capable of receiving multiple labels (in short skipping labels 
until it founds the S bit set)

 
> Perhaps a reasonable approach for 3107bis would be the following:
>  
> - A 3107bis implementation will not send multiple labels to a peer
> unless the Capability has been received from that peer.  (This prevents
> 3107bis implementations from tickling the 'bug' in 3107 implementations.)

Good for me.

> - A 3107bis implementation will accept multiple labels from a peer even
> in the absence of the Capability.

Good for me.
Note that I'm not asking for this route to be installed: I'm fine with 
treat-as-withdraw. But this does imply that the 3107bis speaker be always 
capable of parsing a stack of multiple labels, in order to skip the MPLS stack, 
identify the IP prefix, and treat it as withdraw.

Your approach seems along the line of my original email where I was proposing 
the following change:
"- Even if the capability is not advertised by both peers, and hence a single 
label is expected, all implementations MUST check that the "S" bit (in this 
first label) is set to 1. If the bit is cleared, the Prefix MUST be identified 
as per RFC 3107/this document and treated as withdraw as defined in RFC 7606."
https://mailarchive.ietf.org/arch/msg/mpls/XNhUSSfwTpnOjNZGlpc7O2j3G1g

 
> Another approach would be to have a knob that determines whether the
> Capability needs to be used before multiple labels are advertised.

I'm may be missing what you mean, but that alternative approach does not seem 
to address my concern.

_

Re: [bess] draft-rosen-mpls-rfc3107bis

[Robert Raszuk]

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit
of an interest.

To me the best compromise - which is to agree with Bruno's points as well
as address your intentions is simply to request new SAFI for 3107bis.

>From the draft you are really not updating 3107 base spec but obsoleting it
which to me looks like a bad idea.

You are even requesting to remove IANA reference to original spec. How
would IANA know when is it safe to do that .. meaning when all
implementations will not suddenly support and all deployments will enable
3107bis ?

New SAFI requires a new capability which you are asking for anyway.

As far as implementations please keep in mind very important point that
some implementations treat SAFI 1 & 4 in single table and some in separate
tables. That when mixed with 3107bis may just explode if not in new set of
bugs then with operational nightmare. While we are at this it would be much
cleaner to mandate in the new spec to have 3107bis always to use separate
tables as compared with from SAFI 1.

Thx,
Robert.

PS.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very
well stated that this is only one deployment option for interdomain
encapsulation. I would very much like to see a section indicating that IPv6
or/and IPv4 be used as an alternative encap for those applications which
require it and when needed provide local bindings between intradomain MPLS
and interdomain IP.


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen  wrote:

> On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:
>
>> I'm quite sure you have deployed  implementations, from several
>>> prominent vendors, that will not properly handle this case.
>>>
>> I'm waiting for this/these implementation(s) to make a public statement
>> in this thread / IETF WGs. Then we can discuss whether the issue comes from
>> RFCF3107 or from the implementation.
>> If none make a public statement, we should assume that all
>> implementations are capable of receiving multiple labels, as per RFC 3107.
>>
> I strongly disagree with this.  We should not ignore the facts just
> because you don't like the way the facts were gathered.
>
> A better approach would be to have operators state whether they have any
> deployments in which the "multiple labels" feature is used in a
> multi-vendor environment.  It is very useful when working on a "bis" draft
> to determine which features have been proven to work in a multi-vendor
> environment and which have not.
>
> Any non-compliant implementation may create interoperability issues and
>> unpredictable results.
>>  From an IETF standpoint, the question is whether a RFC 3107
>> implementation would create interoperability issues, up to shutting down
>> the BGP session.
>>
>
> There are deployed 3107 implementations which always assume that the NLRI
> contains a single label.  If you tried to interwork these with 3107
> implementations that send multiple labels , you will experience the kind of
> disruption.  3107bis tries to allow the use of multiple labels while
> preventing this sort of disruption from occurring.
>
> If you mean that some non-compliant implementation do not work, well let's
>> fix them.
>>
>
> The situation is that there is a commonly deployed "bug" in old
> implementations, but it is not seen because the bug is in a feature that no
> one has been using.  If new implementations use that feature, the bug will
> be seen, and network disruption will occur. One could say "fix all the old
> implementations", but it seems wiser to have new implementations avoid
> tickling the bug.   The Capability is not proposed  for the purpose of
> helping the vendors, it's there to help the operators.
>
> I'm not sure why you think there would be BGP session drops due to
> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
> implementation, I think the 3107bis implementation would do
> "treat-as-withdraw" rather than "drop the session".
>
> Perhaps a reasonable approach for 3107bis would be the following:
>
> - A 3107bis implementation will not send multiple labels to a peer unless
> the Capability has been received from that peer.  (This prevents 3107bis
> implementations from tickling the 'bug' in 3107 implementations.)
>
> - A 3107bis implementation will accept multiple labels from a peer even in
> the absence of the Capability.
>
> Another approach would be to have a knob that determines whether the
> Capability needs to be used before multiple labels are advertised.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-rosen-mpls-rfc3107bis

[Eric C Rosen]

On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote:

I'm quite sure you have deployed  implementations, from several
prominent vendors, that will not properly handle this case.

I'm waiting for this/these implementation(s) to make a public statement in this 
thread / IETF WGs. Then we can discuss whether the issue comes from RFCF3107 or 
from the implementation.
If none make a public statement, we should assume that all implementations are 
capable of receiving multiple labels, as per RFC 3107.
I strongly disagree with this.  We should not ignore the facts just 
because you don't like the way the facts were gathered.


A better approach would be to have operators state whether they have any 
deployments in which the "multiple labels" feature is used in a 
multi-vendor environment.  It is very useful when working on a "bis" 
draft to determine which features have been proven to work in a 
multi-vendor environment and which have not.



Any non-compliant implementation may create interoperability issues and 
unpredictable results.
 From an IETF standpoint, the question is whether a RFC 3107 implementation 
would create interoperability issues, up to shutting down the BGP session.


There are deployed 3107 implementations which always assume that the 
NLRI contains a single label.  If you tried to interwork these with 3107 
implementations that send multiple labels , you will experience the kind 
of disruption.  3107bis tries to allow the use of multiple labels while 
preventing this sort of disruption from occurring.



If you mean that some non-compliant implementation do not work, well let's fix 
them.


The situation is that there is a commonly deployed "bug" in old 
implementations, but it is not seen because the bug is in a feature that 
no one has been using.  If new implementations use that feature, the bug 
will be seen, and network disruption will occur. One could say "fix all 
the old implementations", but it seems wiser to have new implementations 
avoid tickling the bug.   The Capability is not proposed  for the 
purpose of helping the vendors, it's there to help the operators.


I'm not sure why you think there would be BGP session drops due to 
3107bis; if a 3107 implementation sends multiple labels to a 3107bis 
implementation, I think the 3107bis implementation would do 
"treat-as-withdraw" rather than "drop the session".


Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer 
unless the Capability has been received from that peer.  (This prevents 
3107bis implementations from tickling the 'bug' in 3107 implementations.)


- A 3107bis implementation will accept multiple labels from a peer even 
in the absence of the Capability.


Another approach would be to have a knob that determines whether the 
Capability needs to be used before multiple labels are advertised.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-rosen-mpls-rfc3107bis

[bruno.decraene]

> From: Eric C Rosen [mailto:ero...@juniper.net] > Sent: Thursday, March 24, 
> 2016 7:14 PM
> On 3/24/2016 11:17 AM, bruno.decra...@orange.com wrote:
> > I don't see why the IETF would want to create a bis which is not
> compatible with the original RFC,
> 
> It's typical in a bis draft to remove features that haven't been used.

- Not by making it non backward compatible with the current RFC, in a way which 
is very disruptive (BGP session shut and the session will stay down or keep 
cycling)
- On a side note, rfc3107bis does not remove the feature to advertise multiple 
labels. 

 
> > especially since this incompatibility may be very disruptive in existing
> networks.
> 
> My belief is that existing deployments don't use or support the multiple
> labels feature,

Do you have data that support this? i.e. there are no deployments and no single 
implementation which advertise multiple labels? That sounds very hard to prove. 
Hence there will be a risk, and this risk is bared by network operators.
I don't see a reason why I would take that risk. 

> and that any attempt to use it as specified in RFC3107
> will itself be disruptive to existing networks,

IMHO RFC3107 is clear enough with respect to the encoding of multiple labels 
inside the BGP UPDATE. I fail to see which point would not be clear to someone.
But this is a theoretical discussion since so far, AFAIK, no major 
implementation has stated that they would not be able to understand NLRI 
received with multiple labels, and hence would shutdown the BGP session.

So I'm waiting for those hypothetical implementations to declare themselves. 
Then we'll see if they are compliant with RFC 3107 or if this is rather an 
implementation issue.


> because it will have
> interoperability issues and unpredictable results.

Any non-compliant implementation may create interoperability issues and 
unpredictable results.
>From an IETF standpoint, the question is whether a RFC 3107 implementation 
>would create interoperability issues, up to shutting down the BGP session.

> Adding the "multiple
> labels" capability is a way to make the feature deployable without
> causing disruption.

I agree with this point.
(although one could also discuss this, at it seems a way to accommodate 
non-compliant implementation)

 
> > "As far as I know" all the implementations claim to be compliant with RFC
> 3107, i.e. are expected to be able to receive multiple labels.
> I'm quite sure you have deployed  implementations, from several
> prominent vendors, that will not properly handle this case.

I'm waiting for this/these implementation(s) to make a public statement in this 
thread / IETF WGs. Then we can discuss whether the issue comes from RFCF3107 or 
from the implementation.
If none make a public statement, we should assume that all implementations are 
capable of receiving multiple labels, as per RFC 3107. And hence there is no 
need to make a 3107bis which is non backward compatible with RFC 3107.

 
> If you do have a deployed implementation that can receive multiple
> labels, what would you expect it to do with those labels? 

A priori, the sender said "For FEC X, uses this label stack", so any behavior 
compliant with this information e.g. what is described in your bis draft 
https://tools.ietf.org/html/draft-rosen-idr-rfc3107bis-00#section-4

> RFC 3107
> doesn't say anything about what to do in this case, it just provides an
> encoding.

RFC3107 describes the BGP encoding, aka "bits on the wire".
It does describe how to send and receive multiple labels from a BGP standpoint. 
This does not involve shutting down the BGP session when multiple labels are 
received.
 
> Have you ever tried to use the "multiple labels" feature?

If you mean by following RFC 3107, I'm not seeing why the BGP session would 
need to be shutdown.
If you mean that some non-compliant implementation do not work, well let's fix 
them.

And I don't see how making a rfc3107bis non backward compatible with RFC 3107 
would improve the situation.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed 

Re: [bess] draft-rosen-mpls-rfc3107bis

[Eric C Rosen]

On 3/24/2016 11:17 AM, bruno.decra...@orange.com wrote:

I don't see why the IETF would want to create a bis which is not compatible 
with the original RFC,


It's typical in a bis draft to remove features that haven't been used.


especially since this incompatibility may be very disruptive in existing 
networks.


My belief is that existing deployments don't use or support the multiple 
labels feature, and that any attempt to use it as specified in RFC3107 
will itself be disruptive to existing networks, because it will have 
interoperability issues and unpredictable results. Adding the "multiple 
labels" capability is a way to make the feature deployable without 
causing disruption.



"As far as I know" all the implementations claim to be compliant with RFC 3107, 
i.e. are expected to be able to receive multiple labels.
I'm quite sure you have deployed  implementations, from several 
prominent vendors, that will not properly handle this case.


If you do have a deployed implementation that can receive multiple 
labels, what would you expect it to do with those labels?  RFC 3107 
doesn't say anything about what to do in this case, it just provides an 
encoding.


Have you ever tried to use the "multiple labels" feature?



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-rosen-mpls-rfc3107bis

[bruno.decraene]

Hi Eric,

Thanks for your reply. Very much appreciated.

Sorry for the delay in responding, but I wanted more time to think about it. 

I'm fine with all your point, except one. Please see inline [Bruno].


> From: Eric C Rosen [mailto:ero...@juniper.net]
> Sent: Friday, January 15, 2016 7:01 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: i...@ietf.org; BESS; m...@ietf.org
> Subject: Re: [bess] draft-rosen-idr-rfc3107bis-00
> 
> Bruno,
> 
> Thanks for reviewing the draft!
> >> - RFC 3107 provides an encoding that allows BGP to assign multiple
> labels
> > Upfront, the current issue is that implementations, which claim
> compliance with RFC 3107, are just non-compliant. So the draft is proposing
> to change the specification to make such implementations compliant, while
> another option would be to fix implementation (to be compliant with the
> RFC they claim to support).
> I think the best approach is to try to write 3107bis in such a way that
> the existing deployed implementations are compliant to it.

[Bruno]
I understand that we have a different perspective on this. Nothing wrong, but 
please find below mine.

On my side, I think that the best approach is to have a 3107bis which is 
backward compatible with RFC3107.
I don't see why the IEFT would want to create a bis which is not compatible 
with the original RFC, especially since this incompatibility may be very 
disruptive in existing networks.


> > The main issue I have, is that this draft is not backward compatible with
> RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not send
> the new capability, and may still send multiple labels). Plus in case of error
> due to this incompatibility, the error handling behavior is likely to be "BGP
> session shutdown" (as the NLRI "cannot" be correctly parsed) which is
> disruptive. Plus the implementation A not supporting multiple labels, will
> claim that the implementation B supporting multiple labels is "not
> compliant" with rfc3107bis, while I would rather argue that this is
> implementation A which is not compliant with RFC 3107.
> Luckily, the existing deployed implementations, as far as I know, do not
> support multiple labels.

[Bruno]
I'm sorry, but I would need more facts on this. In particular which are the 
implementations that are known to be incapable of sending multiple labels, 
today and in the foreseeable future.
And even with such data, there is no guaranty as there may be implementation 
that we don't know about. Therefore, creating this incompatibility is risky. 
(Especially for network operator which are the ones which bare the risk)

>   If a new implementation were to send multiple
> labels to an old implementation, we would likely experience the
> disruptive behavior you describe.  3107bis tries to prevent this
> disruption.

1) again, I appreciate the work being done to handle the fact that some 
implementations are not compliant with RFC 3107.
2) I think you mean :s/old implementation/non compliant RFC 3107 
implementation.  As of today "old implementation" are "existing 
implementations" and they are supposed to be compliant with RFC 3107.
3) "As far as I know" all the implementations claims to be compliant with RFC 
3107, i.e. are expected to be able to receive multiple labels. And for the ones 
which we are using, they may have written this as part of a contractual 
agreement. So before considering making a 3107bis which is non backward 
compatible with RFC 3107, I would like to have the list of those 
implementations. In the absence of this, I assume that current implementations 
are indeed compliant with RFC 3107, just as they claim.

Thanks
-- Bruno

> >
> > I'd propose one change:
> > - Capability means: I don't support receiving multiple labels, hence you
> SHOULD not send that to me.
> > - Even if the capability is not advertised by both peers, and hence a single
> label is expected, all implementations MUST check that the "S" bit (in this
> first label) is set to 1. If the bit is cleared, the Prefix MUST be 
> identified as
> per RFC 3107/this document and treated as withdraw as defined in RFC
> 7606.
> >
> > This means more work for rfc3107bis speakers, but we can't ask existing
> speakers to do the job. Especially since they were compliant with RFC 3107.
> If only a single label is expected, there is no real reason to check the
> S bit.  I'm not sure that all existing implementations actually set the
> S bit, so requiring new implementations to check for it would just
> introduce a possible backwards compatibility problem.
> > Plus very minor comments
> > - From an editorial standpoint, I'd personally favor removing §2.2 and
> saying in 2.3(or elsewhere) that if the capability is not exchanged, a single
> label may be encoded. (IMHO duplicating the text is less easy to read and
> more error prone. And I believe this would be enough to address your point).
> I went back and forth on this issue, and I'd welcome more opinions on
> this from the WG.
> 
> You