Subject: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

From: Jouni Korhonen <[email-masked]>
Date: Tue, 13 Jan 2015 07:28:29 -0800

Folks,

Thanks for the hard work on the -06 revision. Since the changes
from -05 to -06 were many, chairs decided to run another short
WGLC for the WG to verify all changes and discussions are
implemented correctly.

This email starts a one week WGLC #2 for draft-ietf-dime-ovli-06. The
WGLC ends 20th Jan 2015 EOB (PST). Post your review comments and
concerns to the mailinglist. Also make use of the issue tracker
(remember to select "severity" as "in WG last call").

Lionel & Jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Jan 2015 17:56:22 -0600

I think this version is in much better shape, and almost ready to ship. But I still have a few comments:

Substantive:

--Definitions:

I think we've made it too easy for the reader to confuse "abatement mechanisms" with "abatement algorithms". For example, "Abatement Algorithm" starts with "An extensible mechanism..." and "Diversion" starts with "An overload abatement mechanism...". A new reader will likely think that Diversion is a kind of abatement algorithm. I propose the following the following for "Abatement Algorithm":

"An extensible _method_ requested by reporting nodes and used by reacting nodes to determine which requests receive abatement treatment"

For "Diversion":

"An abatement _treatment_ mechanism, where..."

And for "Throttling":

"An abatement treatment mechanism that limits..."

-- 4.3, third paragraph from end:

This still assumes that reporting nodes cannot change algorithms during overload. I thought we agreed to remove that. (The normative text is also still there--see later comment.)

-- section 5.2.1, and subsections:

We still have some awkward use of SHOULDs and MAYs that I think are there to indicate that nodes don't really have to structure their internal state any particular way. But as written, it can be interpreted to allow them to ignore critical pieces of info. We would be better either removing the normative language entirely, or preface the section to say that these represent logical information, and that we do not assume any particular physical structure. (I prefer the latter at this point.) Details:

-- 5.2.1.1: "A reacting node SHOULD maintain...", "The host-type and realm-type OCS entries MAY include..."

What if it doesn't? I think things fail. 

Also, I'm still confused by the first part of this section. The reacting node keeps state for every reported and active overload condition. Each will be the result of a realm report or a host report. The text makes it sound like it needs to keep OCS for both report types, even if it had not received both.

-- 5.2.1.1: "A reporting node SHOULD maintain OCS entries..." and "An OCS entry is identified ... and MAY include ..."

What if it doesn't?

-- 5.2.1.4: "A reporting node MUST NOT update the abatement algorithm in an active OCS entry."

I thought we agreed to remove that, and replace it with the note at the beginning of 5.1?

-- 5.2.2: 5th paragraph:

This doesn't seem quite right, since it leaves the option of no abatement at all. Second, it doesn't seem to allow delegation of abatement downstream. When might one choose to ignore those SHOULDs? Is this here to allow delegation? If so, the use of SHOULD makes local throttling preferred over delegation.

-- 5.3, 4th paragraph:

As I mentioned in previous discussion, after re-reading the related text in 6733, it's no longer clear to me this works like we thought it did. That is, I think any attempt to make sub-AVPs mandatory risks causing errors in the enclosing Diameter transaction. I don't know how to solve this, other just disallowing mandatory sub-AVPs. (Jouni previously convinced me 6733 treatment of the m-bit in sub-avps worked like we wanted--perhaps he can re-convince me :-)  

-- 6.3, paragraph 2:

This is stronger than the SHOULDs in the general behavior section (5.2.2)

Paragraph 5: 

Is this redundant to the last paragraph of 5.2.2?

-- 8, 1st paragraph:

This is just for agents and servers, not clients, right? If so, "When a DOIC node..." is too broadly stated.

Editorial:

-- section 2, "Diversion"

repeated "for".

-- section 3:

I suggest adding a sentence that the same words that are not in all-caps are excepted from the 2119 interpretation.  (We have a few instances of lowercase "must", "should", etc. The uglier alternative would be to hunt down and kill all of them.)

-- 4.3, 4th paragraph from end

s/ "... applying the overload abatement algorithm..." / "... apply the overload abatement algorithm..."

-- Figure 1:

The boxes have caret characters in the top and bottom horizontal lines. Do those mean something?

-- section 5.1.3:

The first two paragraphs conflict with paragraph 4. I think paragraph 4 is correct.

-- 6.3, 4th paragraph:

This seems like a restatement of paragraph 2.

> On Jan 13, 2015, at 9:28 AM, Jouni Korhonen <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Tue, 20 Jan 2015 12:42:38 -0600

The following is the resolution of Ben's issues that were not addressed 
directly in an email thread started by Ulrich.

Regards,

Steve

> I thought we agreed to remove that, and replace it with the note at the beginning of 5.1?
SRD> I have removed the paragraph.
> As I mentioned in previous discussion, after re-reading the related text in 6733, it's no longer clear to me this works like we thought it did. That is, I think any attempt to make sub-AVPs mandato…
SRD>Given that Jouni successfully convinced Ben about the 6733 
treatment, I'm not planning to make any changes, as I'm assuming he can 
be just as successful the second time.
> This is stronger than the SHOULDs in the general behavior section (5.2.2)
SRD> Section 5.2.2 says:

    If the request matches an active OCS then the reacting node MUST use
    the overload abatement algorithm indicated in the OCS to determine if
    the request is to receive overload abatement treatment.

Section 6.3 says:

    When receiving an OC-OLR in an answer message where the algorithm
    indicated in the OC-Supported-Features AVP is the loss algorithm, the
    reacting node MUST apply abatement treatment to the requested
    percentage of request messages sent.

I don't see the issue.
> Is this redundant to the last paragraph of 5.2.2?
SRD> I don't see an issue.  One is general and the other specific to the 
loss algorithm.  They don't conflict.
> -- section 2, "Diversion"
SRD> Changed
> repeated "for".
SRD> Changed
> I suggest adding a sentence that the same words that are not in all-caps are excepted from the 2119 interpretation.  (We have a few instances of lowercase "must", "should", etc. The uglier alternat…
SRD> Done. Section 3 now contains the following:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

    RFC 2119 [RFC2119] interpretation does not apply for the above listed
    words when they are not used in all-caps format.

> s/ "... applying the overload abatement algorithm..." / "... apply the overload abatement algorithm..."
SRD> Done
> The boxes have caret characters in the top and bottom horizontal lines. Do those mean something?
SRD> I removed the carets.  I think they were just meant to be decorative.
> This seems like a restatement of paragraph 2.
SRD> I removed the 4th paragraph.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Jan 2015 13:20:47 -0600

> On Jan 20, 2015, at 12:42 PM, Steve Donovan <[email-masked]> wrote:
> 
> The following is the resolution of Ben's issues that were not addressed directly in an email thread started by Ulrich.
> 
> Regards,
> 
> Steve 
> 
>> 
>> -- 5.3, 4th paragraph:
>> 
> SRD>Given that Jouni successfully convinced Ben about the 6733 treatment, I'm not planning to make any changes, as I'm assuming he can be just as successful the second time. 

I think that's a bad assumption.

We had previously assumed that if a node receives a grouped AVP (without the m-bit set) that includes an unrecognized sub-avp with the m-bit set, then the receiver could just ignore the entire grouped AVP, and otherwise process the transaction. But 6733 actually says the following:

"Receivers of a Grouped AVP that
   does not have the 'M' (mandatory) bit set and one or more of the
   encapsulated AVPs within the group has the 'M' (mandatory) bit set
   MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
   rule applies even if the encapsulated AVP with its 'M' (mandatory)
   bit set is further encapsulated within other sub-groups, i.e., other
   Grouped AVPs embedded within the Grouped AVP."

Note the "... if the Grouped AVP itself is unrecognized." clause.

The case we have in mind is when you receive a _recognized_ grouped AVP (that is, you implement DOIC), but it includes an unrecognized sub-avp with the M-bit set. This is not covered by the exception. This would seem to indicate that the entire request must fail. I don't think that's what we want.

At this point, I think we need to either say that sub-avps of DOIC grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT have the m-bit set unless the sub-avp is part of an extension explicitly negotiated in the feature vector.

>    percentage of request messages sent.

I was referring to the "SHOULD apply diversion, else SHOULD apply throttling" language. But that's been fixed as part of a separate discussion.

> SRD> I don't see an issue.  One is general and the other specific to the loss algorithm.  They don't conflict.

The one in 5.2.2 is specific to situations where an OLR quenches all requests, and says MUST. So is this, and says RECOMMENDED (which means SHOULD in 2119).

If the idea is that the text in 6.3 is the recommended way to fulfill the MUST in 5.2.2, then that's okay I guess (although I would prefer one of the two to be non-normative.)

Another approach would to leave this to 6.3, and add something to the effect that any new algorithm that can cause total quenching of requests must address how the reacting node restarts from that state. 

[...]

---

From: Steve Donovan <[email-masked]>
Date: Tue, 20 Jan 2015 15:08:55 -0600

> The case we have in mind is when you receive a _recognized_ grouped AVP (that is, you implement DOIC), but it includes an unrecognized sub-avp with the M-bit set. This is not covered by the excepti…
SRD> I see how it could be interpreted that way.
> At this point, I think we need to either say that sub-avps of DOIC grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT have the m-bit set unless the sub-avp is part of an extension e…
SRD> I'm ok either way but prefer number 2).
[...]
> The one in 5.2.2 is specific to situations where an OLR quenches all requests, and says MUST. So is this, and says RECOMMENDED (which means SHOULD in 2119).
SRD>Actually 5.2.2 isn't only about quenching.  It's also about the 
reacting node having sent no traffic, because it had no traffic to send, 
and now needs to send traffic soon after the OCS expires. The reporting 
node might still be in an overload state but the reacting node doesn't 
know until the first request is sent.
> If the idea is that the text in 6.3 is the recommended way to fulfill the MUST in 5.2.2, then that's okay I guess (although I would prefer one of the two to be non-normative.)
SRD> 6.3 deals specifically with quenching, thus is a little different 
than 5.2.2, although there is overlap.
> Another approach would to leave this to 6.3, and add something to the effect that any new algorithm that can cause total quenching of requests must address how the reacting node restarts from that…
SRD> I prefer to leave it as it currently is.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 22 Jan 2015 08:38:24 -0600

All,

We need to close these two issues to finish WGLC #2.

Please review an let me know if the alternatives I have outlined below 
are acceptable.

Thanks,

Steve

On 1/20/15 3:08 PM, Steve Donovan wrote:
>>> The following is the resolution of Ben's issues that were not 
>>> addressed directly in an email thread started by Ulrich.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>> -- 5.3, 4th paragraph:
>>>>
>>>> As I mentioned in previous discussion, after re-reading the related 
>>>> text in 6733, it's no longer clear to me this works like we thought 
>>>> it did. That is, I think any attempt to make sub-AVPs mandatory 
>>>> risks causing errors in the enclosing Diameter transaction. I don't 
>>>> know how to solve this, other just disallowing mandatory sub-AVPs. 
>>>> (Jouni previously convinced me 6733 treatment of the m-bit in 
>>>> sub-avps worked like we wanted--perhaps he can re-convince me :-)
>>>>
>>> treatment, I'm not planning to make any changes, as I'm assuming he 
>>> can be just as successful the second time.
>> We had previously assumed that if a node receives a grouped AVP 
>> (without the m-bit set) that includes an unrecognized sub-avp with 
>> the m-bit set, then the receiver could just ignore the entire grouped 
>> AVP, and otherwise process the transaction. But 6733 actually says 
>> the following:
>>
>> The case we have in mind is when you receive a _recognized_ grouped 
>> AVP (that is, you implement DOIC), but it includes an unrecognized 
>> sub-avp with the M-bit set. This is not covered by the exception. 
>> This would seem to indicate that the entire request must fail. I 
>> don't think that's what we want.
>> At this point, I think we need to either say that sub-avps of DOIC 
>> grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT 
>> have the m-bit set unless the sub-avp is part of an extension 
>> explicitly negotiated in the feature vector.
>> The one in 5.2.2 is specific to situations where an OLR quenches all 
>> requests, and says MUST. So is this, and says RECOMMENDED (which 
>> means SHOULD in 2119).
> reacting node having sent no traffic, because it had no traffic to 
> send, and now needs to send traffic soon after the OCS expires. The 
> reporting node might still be in an overload state but the reacting 
> node doesn't know until the first request is sent.
>>
>> If the idea is that the text in 6.3 is the recommended way to fulfill 
>> the MUST in 5.2.2, then that's okay I guess (although I would prefer 
>> one of the two to be non-normative.)
>> Another approach would to leave this to 6.3, and add something to the 
>> effect that any new algorithm that can cause total quenching of 
>> requests must address how the reacting node restarts from that state.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 22 Jan 2015 16:41:48 +0000

Dear all,

A) About 'M' bit:

My understanding of RFC6733:

      The 'M' bit, known as the Mandatory bit, indicates whether the
      receiver of the AVP MUST parse and understand the semantics of the
      AVP including its content.  The receiving entity MUST return an
      appropriate error message if it receives an AVP that has the M-bit
      set but does not understand it.  An exception applies when the AVP
      is embedded within a Grouped AVP.  See Section 4.4 for details.

       4.4:
   Receivers of a Grouped AVP that
   does not have the 'M' (mandatory) bit set and one or more of the
   encapsulated AVPs within the group has the 'M' (mandatory) bit set
   MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
   rule applies even if the encapsulated AVP with its 'M' (mandatory)
   bit set is further encapsulated within other sub-groups, i.e., other
   Grouped AVPs embedded within the Grouped AVP.

If the Grouped AVP does not have the 'M' bit set, but one (or more) of its sub-AVPs do have it, then the grouped AVP may be ignored (instead of sending an error) if the Grouped AVP itself is "unrecognized"
But what "unrecognized" mean in this context? In my opinion, the grouped AVP is not recognized as long as mandatory sub-AVPs are missed, this includes conditionally mandatory (up to negotiation) sub AVPs.
Then I would proposed a variant to your proposal 2 below:

3) sub-AVPs of DOIC grouped AVPs MUST NOT  have the m-bit set unless the sub-avp is mandatory or conditionally mandatory (i.e. part of an extension explicitly negotiated in the feature vector).

B) Going out of 100% reduction

I think we should keep 5.2.2 as it is.
But I think there is a bit of misalignment with 6.3. I will propose following rephrasing:

Now: 5th paragraph:

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out, the following procedures
   are RECOMMENDED to be applied.  The reacting node sending the traffic
   should be conservative and, for example, first send "probe" messages
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.

Proposed: 5th paragraph:

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out,					<--
                                                                the reacting node sending the traffic	<--
   SHOULD be conservative and, for example, first send "probe" messages	<--
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: jueves, 22 de enero de 2015 15:38
To: [email-masked]
Subject: Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

All,

Please review an let me know if the alternatives I have outlined below are acceptable.

Thanks,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jan 2015 15:33:44 -0600

On Jan 22, 2015, at 10:41 AM, Maria Cruz Bartolome <[email-masked]> wrote:

A) About 'M' bit:

      4.4:

That's not what "unrecognized" typically means in IETF specs. The common usage is to mean that the recipient doesn't recognize it, or doesn't know what it means. This is  distinct from "malformed" meaning it wasn't constructed correctly.  Missing mandatory sub-AVPs would fall into the "malformed" category, not the "unrecognized" category. .
By definition, a DOIC cannot claim OC-Supported-Features or OC-OLR as unrecognized. 

Also, the M-bit doesn't mean the avp is mandatory to be present, just mandatory to be understood. By definition, you can't set the M-bit on an AVP that is not actually there.  (Other things may make it mandatory to be present, such as the feature or application definition, but that still doesn't necessarily mean it's mandatory to understand.) It's also possible that some new feature will involve an AVP that is not there all the time, but mandatory to understand when it is there..

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Jan 2015 15:37:23 -0600

On Jan 20, 2015, at 3:08 PM, Steve Donovan <[email-masked]> wrote:

I'm okay with 2, but it's really a bit redundant. If the AVP is a required-to-understand part of an extension, then negotiating the extension should be sufficient. The M-bit adds no additional semantics.

Basically, we are trying to say "never set the M-bit in a way that could cause a transaction to fail." That means either never setting it, or only setting it if you already know the recipient understands the AVP. Or more to the point, "Never set the M-bit unless the M-bit would be irrelevant anyway".

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 23 Jan 2015 09:28:48 +0000

Ben,

for my clarification:
this issue seems to be a general thing and not related specifically to DOIC. 

Any potential modification, addition, clarification,... would not impact DOIC but RFC6733.
Is this the correct understanding?

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Thursday, January 22, 2015 10:34 PM
To: Maria Cruz Bartolome
Cc: [email-masked]
Subject: [Dime] DOIC M-Bit usage (was Re: WLGC #2 for draft-ietf-dime-ovli-06)

A) About 'M' bit:

      4.4:

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 23 Jan 2015 09:46:26 +0000

See below
Thanks

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: jueves, 22 de enero de 2015 22:34
To: Maria Cruz Bartolome
Cc: Steve Donovan; [email-masked]
Subject: DOIC M-Bit usage (was Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06)

A) About 'M' bit:

      4.4:

[MCruz] Any mandatory or conditionally mandatory AVP, it is as well mandatory to be understood by any DOIC-enabled.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Jan 2015 07:17:21 -0600

I would propose the following resolution to the M-bit issue:

1) We say that new extensions MUST NOT require the M-bit be set for new 
sub-AVPs of the OC-Supported-Features AVP or the OC-OLR AVP.

2) We indicate that if there a new extension includes behavior that 
requires 6733 defined M-bit behavior then the new extension can define a 
new AVP.  It just can't make that new AVP part of OC-Supported-Features 
or OC-OLR.

Does this address everyone's concerns?

Steve

On 1/23/15 3:46 AM, Maria Cruz Bartolome wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJUwWy4AAoJEIBWSmyV89QNV70P/ji24iU2Wr93uGIjK79hSNIR
> Bnab4rva2MHeGufWvTzYsvXwCYUaWOeb7y4Z5T1dRgPOPw4JNKQ5cnoEMjIMmWJu
> J4ocoZlAR7ujKBOlTnvf1FlFEPDQ6emanxcRZD9+nTQPaC54gnMgf6CfWyQBgIia
> oVGMEg2C/+yzx4NtuGAwqpJ4dVe/33VMpl4lG7KG4JQMzLYxyWIiiLDvA8SQXoxU
> rLLVvkvKWp2hKdjO7zxpTY6Vd2DqYawU/Z25yWBAUmDFWziJwh6HD2P38F/KNszZ
> kpRJD3WrjGdlmPKatooNwCHz60hjP2lFXlS7vocNAWuug4dAyPNZarl3G+ZSAhtB
> Wud/vThdWwknGM9TbumDW5FM8kJoUPSjTICtaSG3jsnW2qPKAcikSubmepc5KXDg
> Dap50sTL9XfM1WNIqiM1H/DdsQnEJfqgPJ7Nce+mzllMAFHVL7hOIyf2zpb8vPtt
> Nq5FuCbDr4qK7IZxX+OzFuUJC+aT3ajWt6lZLjZmcHnObOfgTCDggWspWXzlNY+X
> oYgH3DT6/j4jNkOZGcw7cOw1xHIQQWwxLEJkLIQwJiKeZHcOYbZ69LuEZ8k7mXZ3
> cCDvnggXLujLZE5F4D/LtLq5MMrwGWtLiNN1DOBX3iH5EKE/YK0nsbFD+DKR9AiF
> LdvuO+g1/k8sGzWJgxkr
> =+wlK
> -----END PGP SIGNATURE-----

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Jan 2015 07:38:29 -0600

I'm ok with Maria Cruz's suggested change.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 Jan 2015 09:12:56 -0600

> On Jan 23, 2015, at 3:28 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:
> 
> Ben,
> 
> for my clarification:

Not really. I think the way 6733 describes things was as intended for the general case. It's there so that the recipient doesn't have to recurse all the way through a bunch of nested group AVPs just to make sure there aren't any M-bits set.  

DOIC is unusual here, in that we are piggybacking info onto an existing application. We don't want to induce a failure in that application because of an error in DOIC.

> Signed PGP part

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 Jan 2015 09:15:11 -0600

What's the point of 2)? It still introduces a way that a DOIC extension might cause the application transaction to fail. Do we want that?

On Jan 23, 2015, at 7:17 AM, Steve Donovan <[email-masked]> wrote:

1) We say that new extensions MUST NOT require the M-bit be set for new sub-AVPs of the OC-Supported-Features AVP or the OC-OLR AVP.

2) We indicate that if there a new extension includes behavior that requires 6733 defined M-bit behavior then the new extension can define a new AVP.  It just can't make that new AVP part of OC-Supported-Features or OC-OLR.

Steve

- -----Original Message-----

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

A) About 'M' bit:

      4.4:

- -----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

=+wlK
- -----END PGP SIGNATURE-----

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Jan 2015 09:41:39 -0600

> 2) We indicate that if there a new extension includes behavior that requires 6733 defined M-bit behavior then the new extension can define a new AVP.  It just can't make that new AVP part of OC-Sup…
SRD> Well, there's nothing we can do to prevent it, which makes it 
redundant to even say it.  So, I plan to do 1).  I'll wait until Monday 
to publish -07 (assuming we have resolution to all the issues) to give 
our European friends a chance to comment.
> iQIcBAEBCgAGBQJUwmV/AAoJEIBWSmyV89QNk/gQAMTubMzk/y3Ia3thiWAH8K/2
> j9VnwHFsza62G3uMLmYQ8tZNsXgidOF+F6WwC6hZRZK/QX3tNTLbnF4FjyFn2fhO
> eE0D00mDbp/kngMITrxVHTGghocSBxGHyNntQKwrIxV7gVYIxEbMUL8ouKvO9Do8
> NOi9K/he1iiK0pCNcQ9UstU8ZQm5kPyqMVGLhsHLEe779qTfE6fF5ppeJgATPyJl
> 1wNHgBoh9XcGPJdYO4MzcSn/hO9+tC9Ngp2lO0w4Q2SHgwh1W3kRODwLtNWq8pcg
> JcSb6UtcQ/jVdOCF23/eZ3OhXgC8q01j2tp0YGVXGqPf4ePPU10uAW/8lioEwbRH
> iiqOiSSEPbjjMb3yVDc/cu78Iq8NGr8n7iEiQwlPCs8Vlv7Nj7xv2Lmyk8LlDz4q
> /HAozquUXgHwaYuKtzH7QBf+79rinPJAjomv10tzMSHk/Tu5aq0KFI41jqUra1i/
> 0xu9TnMDmEseL5rjMpkQ1Cw69H/etoh7+93jt3nGJUoLL7+eGoq0Z8pkl3Ukeihu
> 1DjigPWkbsfGtp0Iw0FKvtVMjSqFgFyH2y/k3u2Xiiz5k/e6mdqp3UnsHuc6MPUy
> 4fULg+SShkAMnk5BFjG4KKFWdTBhVn5X8O8lhgzfJ46SYkdAo2qw9YEd19CtJK5E
> yvE5D9UmNsXqEjh+t/yp
> =mnr3

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 Jan 2015 09:43:25 -0600

On Jan 23, 2015, at 9:41 AM, Steve Donovan <[email-masked]> wrote:

2) We indicate that if there a new extension includes behavior that requires 6733 defined M-bit behavior then the new extension can define a new AVP. It just can't make that new AVP part of OC-Supported-Features or OC-OLR.
SRD> Well, there's nothing we can do to prevent it, which makes it redundant to even say it.  So, I plan to do 1).  I'll wait until Monday to publish -07 (assuming we have resolution to all the issues) to give our European friends a chance to comment.

Works for me.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 Jan 2015 09:50:08 -0600

Works for me.