Lou,
Thanks for the response. I think that settles the "update" debate.Elwyn, Hi!
Are you satisfied with my other responses? I'll submit a new revision as agreed in my responses.
On Fri, Oct 6, 2017 at 3:31 PM, Lou Berger <lberger@xxxxxxxx> wrote:
Hi Pavan,
On 10/05/2017 07:44 AM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
>
> Responses inline (prefixed PB).
>
> Regards,
> -Pavan
>
> From: Lou Berger <lberger@xxxxxxxx <mailto:lberger@xxxxxxxx>>
> Date: Thursday, October 5, 2017 at 6:41 AM
> To: "EXT-vishnupavan@xxxxxxxxx <mailto:EXT-vishnupavan@gmail.com >"
> <vishnupavan@xxxxxxxxx <mailto:vishnupavan@xxxxxxxxx>>, Elwyn Davies
> <elwynd@xxxxxxxxxxxxxx <mailto:elwynd@xxxxxxxxxxxxxx>>
> Cc: "gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx>" <gen-art@xxxxxxxx
> <mailto:gen-art@xxxxxxxx>>,
> "draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx
> <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx >"
> <draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx
> <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx >>,
> "teas@xxxxxxxx <mailto:teas@xxxxxxxx>" <teas@xxxxxxxx
> <mailto:teas@xxxxxxxx>>, ietf <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>
> Subject: Re: [Teas] Genart last call review of
> draft-ietf-teas-rsvp-te-scaling-rec-06 The RFC doesn't generally review unmodified RFC2205 processing, nor has
>
> Hi Pavan,
>
> WRT if this document updates rfc2961:
>
> I don't have a strong opinion on or objection to this document updating
> rfc2961. To have this document be an update, I do think we and it need
> to be clear on what exactly is being updated in 2961. After rereading
> both it's unclear to me what you see is being updated. As best I can
> see, this document basically relates to 2961 in that it says (a) use the
> reliable message delivery defined in 2961 and (b) restates that 2205
> refresh processing of path and resv messages still applies after a rapid
> retry period expires and (c) sending acks moves from recommended to
> required.
>
> What did I miss?
>
> FWIW I think (a) and (c) are requirements of this document not 2961 and
> (b) seems like an informative statement that the basic refresh
> processing rules of rfc2205 still apply.
>
> --
> [PB] This is all about how we interpret (b). RFC2961 doesn’t explicitly
> state what happens the rapid retry period expires. The current draft
> explains what needs to be done. Does this warrant an official update to
> RFC2961?
that been the normal practice when defining RSVP extensions. An
informative statement in this draft certainly would do no harm if you
feel that it is needed, but I don't think it raises to the level of an
update.
Thanks,
Lou
> —
>
> Thanks
> Lou
>
> On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram <vishnupavan@xxxxxxxxx
> <mailto:vishnupavan@xxxxxxxxx>> wrote:
>
>> Elwyn, Hi!
>>
>> Please see inline for responses.
>>
>> Regards,
>> -Pavan
>>
>> On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <elwynd@xxxxxxxxxxxxxx
>> <https://urldefense.>> <mailto:elwynd@xxxxxxxxxxxxxx>> wrote:
>>
>>
>>
>> Hi, Pavan.
>>
>> I've checked through the changes in -07 and I think all is good as
>> regards fixing the 'major issue', restucturing s2 and fixing the
>> nits - thanks.
>>
>>
>> [Pavan] Great!
>>
>>
>> Looking at the IESG comments I think you have covered most of
>> them except it would be good to put a pointer to Appendix A into
>> the intro of s2.
>>
>> With reference to Appendix A(d), it would be helpful to s/periodic
>> retransmission interval/Periodic Retransmission Interval/ and
>> possibly give it a name (Rpri or some such) in s2.3 and Appendix
>> A(d). Adding the name of the interval after "retransmission of
>> these on a slower timer" migt mak it clearer also.
>>
>>
>> [Pavan] Ok. We'll add a pointer to the Appendix and also find a short
>> form for the periodic retransmission interval.
>>
>>
>> However, I think you still need to address all three of the minor
>> issues:
>> - Capability object: A 'basic' implementation of RFC 2209/RFC3209
>> will not include the RFC5063 extensions.
>>
>>
>> [Pavan] I think you meant RFC2205 and not RFC2209.
>>
>> I think you should therefore make it explicit that a prerequisite
>> for your extensions is an implementation of the Capability object
>> as specified in RFC5063 (my proposal for s3) , making it clear
>> that this does not require any of the other functionality of RFC
>> 5063, especially no support for the S bit in the Capabilities.
>>
>>
>> [Pavan] I'm not really sure that "Capability Object" needs a separate
>> prerequisite section. I'll let the Document-Shepherd and our AD take a
>> call on this. Please note that the document also talks about using
>> Node-ID hellos from RFC4558. Would "Node-Hellos/RFC4558" also then
>> need a separate prerequisite section? We added a separate section for
>> RFC2961 because there is a need to explicitly clarify the usage of
>> certain 2961 procedures. With "Capability Object" and "Node Hellos",
>> there isn't anything (IMHO) that needs to be explicitly clarified. We
>> could just add a statement in Section 4.1 saying that you don't need
>> to set any other flags. Would that address your concern about the
>> ambiguity regarding the "Graceful Restart" bits?
>>
>> OLD
>> An implementation supporting the RI-RSVP technique
>> MUST set a new
>> flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
>> messages.
>> NEW
>>
>> An implementation supporting the RI-RSVP technique MUST set a new
>> flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
>> messages. This MAY be the only flag set in the object.
>>
>>
>> - Your response regarding what happens if a peer initially
>> acknowledges that it supports the new capabilities by setting the
>> I/F bits in the Capability and sends some messages with the
>> Refresh-Reduction-Capable bit set, but then stops setting the
>> Refresh-Reduction-Capable bit doesn't really address the problem.
>> Would this mean that the receiver should assume that the peer can
>> no longer support the extensions?
>>
>>
>> [Pavan] Yes.
>>
>> Is this a permanent state or could the peer start setting the
>> Refresh-Reduction-Capable bit again and restore initial
>> functionality - or should this just not be allowed.
>>
>>
>> [Pavan] The peer can set the bit again and restore the functionality.
>>
>> I think you need to think through what happes in the various
>> possible cases and explain what an implementation should do in
>> each case.
>>
>>
>> [Pavan] There are only two possibilities -- Is the functionality
>> enabled on the peer or is it not? If the functionality is enabled, the
>> implementation does everything that is specified as required for the
>> given technique. If it is not enabled, then the implementation doesn't
>> employ the technique and just behaves like it does today. We'll try
>> and add some text to make this obvious.
>>
>>
>> - So, I have done my homework and checked back on what happens
>> when there is no acknowledgement of refreshes. The relevant
>> parameter is the cleanup time. However, this leaves us with a
>> problem.. the cleanup time is typically set as a multiple of the
>> refresh interval (9 times seems to be the default) - indeed I see
>> that the interface configuration on a Juniper router (!) actually
>> sets it by asking for the multiple rather than an absolute value.
>> Wth the new dispensation in ths document, there are two time
>> periods involved: I think you do need to respecify how to
>> calculate a sensible cleanup interval, and note that the
>> retransmissions will then halt after this interval.
>>
>>
>> [Pavan] I think you are confusing this with the "setup retry" timer
>> (which comes into play when you signal the PATH setup of an LSP
>> instance and don't get a RESV back). Please go through
>> https://tools.ietf.org/html/draft-ravisingh-teas-rsvp- setup-retry-01
proofpoint.com/v2/url?u=https- >3A__tools.ietf.org_html_draft- 2Dravisingh-2Dteas-2Drsvp- 2Dsetup-2Dretry-2D01&d=DwMDaQ& c=HAkYuh63rsuhr6Scbfh0UjBXeMK- ndb3voDTXcWzoCI&r= CFHVfW0WsgxSqM6wTJiWE5evUJAdlU l1fm7E0WVbiS8&m=k7e- cloxf90XW9b_KRgpp7fxJRT4Q-f-_ Nor0jTe8fg&s= XXwwGPXiCQhVIgNDbiHxKEuHs1fkmM oiGQsHcQ33ZQE&e=
>> <mailto:vishnupavan@xxxxxxxxx>>> for a detailed account of setup retry timer, issues associated with it
>> and recommended practices. The staged retransmission (Section 2.3)
>> that comes into play when there is no ACK is different from what you
>> are alluding to -- it is meant for any message seeking ACK (not just
>> PATH). This is very specific to the exponential back-off procedure
>> discussed in Section 6 of RFC2961. As per RFC2961, the rapid
>> retransmissions stop after we reach a certain retry limit. In Section
>> 2.3, we are clarifying what needs to be done after this Retry limit is
>> reached --- the recommendation is to fall back on a not so rapid
>> retransmission interval. As a I said in my previous email, this needs
>> to be done until either an ACK is received or the corresponding state
>> is torn down.
>>
>>
>> Does this last modification constitute an update of RFC 2209? I
>> am not sure -consult your AD!
>>
>>
>> [Pavan] RFC2209 is an informational document that provides guidance on
>> the various data-models and procedures needed for an implementation to
>> be RFC2205 compliant. Most of the content in RFC2209 is outdated
>> (imho). No one has had the inclination over the years to update this
>> and we don't intend to do this either.
>>
>> [Pavan] Reading through the various questions/comments from the IESG,
>> I'm convinced that this document needs to formally update RFC2961.
>> We'll go ahead and do that if the shepherd and our AD have no objections.
>>
>>
>>
>> Regards,
>> Elwyn
>>
>> Sent from Samsung tablet.
>>
>> -------- Original message --------
>> From: Vishnu Pavan Beeram <vishnupavan@xxxxxxxxx
> >> <mailto:elwynd@xxxxxxxxxxxxxx>
>> Date: 28/09/2017 03:48 (GMT+00:00)
>> To: Elwyn Davies <elwynd@xxxxxxxxxxxxxx
>
>> Cc: gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx>,
>> draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx
>> <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@xxxxxxxx >, ietf
>> <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>, teas@xxxxxxxx
>> <mailto:teas@xxxxxxxx>
>> Subject: Re: [Teas] Genart last call review of
>> draft-ietf-teas-rsvp-te-scaling-rec-06 >> <https://urldefense.
>>
>> Elwyn, Hi!
>>
>> Thanks for the detailed review and the text suggestions. We just
>> posted a new revision (-07) to address the concerns listed below.
>> Please go through the new diffs
>> (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te- scaling-rec-07
proofpoint.com/v2/url?u=https- 3A__www.ietf.org_rfcdiff- 3Furl2-3Ddraft-2Dietf-2Dteas- 2Drsvp-2Dte-2Dscaling-2Drec- 2D07&d=DwMDaQ&c= HAkYuh63rsuhr6Scbfh0UjBXeMK- ndb3voDTXcWzoCI&r= CFHVfW0WsgxSqM6wTJiWE5evUJAdlU l1fm7E0WVbiS8&m=k7e- cloxf90XW9b_KRgpp7fxJRT4Q-f-_ Nor0jTe8fg&s=xuSuAQ7BlTuE-ue- 3t5WtAzMMA9cBuBNzk4iM7yoTHs&e= >)
>> and let us know if additional changes are required.
>>
>> Please see inline for further responses (prefixed VPB).
>>
>> Regards,
>> -Pavan
>>
>> On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies
>> <elwynd@xxxxxxxxxxxxxx <mailto:elwynd@xxxxxxxxxxxxxx>> wrote: >> <https://urldefense.
>>
>> Reviewer: Elwyn Davies
>> Review result: Not Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General
>> Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
proofpoint.com/v2/url?u=https- >>.3A__trac.ietf.org_trac_gen_ wiki_GenArtfaq&d=DwMDaQ&c= HAkYuh63rsuhr6Scbfh0UjBXeMK- ndb3voDTXcWzoCI&r= CFHVfW0WsgxSqM6wTJiWE5evUJAdlU l1fm7E0WVbiS8&m=k7e- cloxf90XW9b_KRgpp7fxJRT4Q-f-_ Nor0jTe8fg&s= 7EVfFwYHvGi6M8T035d7tGPQVwgnEJ q_TzB3RddVx2Q&e=
>> Teas@xxxxxxxx <mailto:Teas@xxxxxxxx>>>
>> Document: draft-ietf-teas-rsvp-te-scaling-rec-06
>> Reviewer: Elwyn Davies
>> Review Date: 2017-09-22
>> IETF LC End Date: 2017-09-22
>> IESG Telechat date: 2017-09-28
>>
>> Summary: Not ready, primarily because the title and
>> presentation give the
>> impression that the content is really a BCP when it isn't.
>> This conceals the
>> considerable amount of tweaking of RFC 2961 functionality and
>> addition of new
>> RSVP Capabilities described in the document. There are also a
>> couple of minor
>> issues that need to be sorted out.
>>
>> Major issues:
>> Title and way proposals are presented: The document defines
>> two new
>> 'capabilities' for RSVP-TE and is indeed (as specified in the
>> document header)
>> correctly intended for Standards Track status. However the
>> title and the whole
>> of the meat of the document in Section 2 presents the proposals as
>> 'recommendations' which says to me that I am expecting a BCP
>> where a profile of
>> available options from existing standards is recommended as
>> the best choice for
>> implementation and deployment. In my opinion, the title would
>> be better as
>> something like "Additional Capabilities Designed to Improve
>> the Scalability of
>> RSVP-TE Deployments". Whilst the proposals are based on the
>> techniques in RFC
>> 2961, the document *requires* the implementor to conform to
>> rules that were
>> optional and constrains configurable values to different
>> ranges in order to be
>> able to deliver the capabilities defined in the document as
>> well as defining
>> new RSVP extensions modifying some of the behaviour defined in
>> RFC 2961. Thus
>> although some of the rules could be met by choosing particular
>> values within
>> the RFC 2961 set, the use of MUST, tweaking of functionality
>> and variation of
>> ranges takes it well beyond a set of recommendations for RFC
>> 2961 options
>> selections. In view of this Section 1 needs to be written as
>> an introduction
>> to the definitions of the new capabilities rather than
>> advocacy for selection
>> of RFC 2961 options and the implication that the techniques
>> mentioned in the
>> last paragraph of s1 are just a matter of selecting a profile
>> of option values.
>> In actuality new protocol values are introduced and ss2.2 and
>> 2.3 define novel
>> extensions to RSVP beyond what is available for RFC 2961 and
>> requiring
>> modification to basic RFC 2961 functionality..
>>
>>
>> [VPB] We changed the title to "Techniques to Improve the
>> Scalability of RSVP-TE Deployments". We also tweaked the text in
>> the introduction section as suggested. Please see if the new set
>> of diffs address the comment above.
>>
>> Minor issues:
>> Interaction with RFC 5063: The document does not explicitly
>> state that an
>> implementation would need to support (at least) the extra
>> capability obect
>> defined in s4.2 of RFC 5063. Some words about interaction
>> with RFC 5063 are
>> probably required in that s4.2.1 of RFC 5063 rather assumes
>> that if there is a
>> capability object, by default its S bit will be set.
>>
>>
>> [VPB] The CAPABILITY object in RFC5063 is meant for generic use
>> and can be used even when there are no Graceful Restart extensions
>> in play (even when no GR flags are set). As far as we can tell,
>> there is nothing in RFC5063 that precludes this. We added a
>> reference to RFC5063 when the new Capability flags are introduced.
>> Would this be sufficient to address this concern?
>>
>>
>>
>> Behaviour if a node stops setting Refresh-Reduction-Capable
>> bit: The last para
>> of s2 in RFC 2961 discusses behaviour if a node stops setting
>> this bit in
>> messages. What would happen with the extensions defined in
>> this document if
>> this happened while either of the extensions is in use? As a
>> matter of
>> interest, if a peer offers the capabilities defined in this
>> draft, is it
>> possible or sensible for it to stop setting the
>> Refresh-Reduction-Capable bit
>> without stopping offering the extensions?
>>
>>
>> [VPB] If a peer sets the I or F bit in the CAPABILITY object but
>> does not set the Refresh-Reduction-capable bit, then the
>> corresponding functionality ("RI-RSVP" or "Per-Peer Flow-Control")
>> is not activated for that peer. In other words, resetting the
>> Refresh-Reduction-Capable bit immediately makes the node incapable
>> of supporting the two capabilities discussed in this document.
>> This is covered in Sections 3.1 and 4.1 ( -07 version).
>>
>>
>> s2.1.3, para 2: As specified, it appears that the 'slower
>> timer' transmission
>> of Path and Resv messages can go on indefinitely if no ack
>> arrives. What puts
>> an end to this repetition? [It may be that I have forgotten
>> how basic RSVP
>> works, but since this is altering the behaviour it would be
>> good to explain how
>> it terminates, and whether this requires any additional
>> modification to timers.]
>>
>>
>> [VPB] There is nothing new about Path and Resv messages getting
>> transmitted indefinitely (this is normal soft-state signaling
>> behavior) -- all that this section does is discuss how these
>> transmissions are paced in the absence of an ack. The slower timer
>> transmission will go on until either an ack is received (at which
>> point the regular "refresh interval" comes into play) or the
>> corresponding LSP instance state is torn down.
>>
>>
>> Nits/editorial comments:
>> Abstract: RSVP-TE is not a 'well-known' abbreviation:
>> s/RSVP-TE/RSVP Traffic
>> Engineering (RSVP-TE)/
>>
>>
>> Abstract and s1, first para: This para is not future proof.
>> Suggest:
>> OLD:
>> The scale at which RSVP-TE [RFC3209] Label Switched Paths
>> (LSPs) get
>> deployed is growing continually and there is considerable
>> onus on
>> RSVP-TE implementations across the board to keep up with this
>> increasing demand in scale.
>> NEW:
>> At the time of writing, networks which utilise RSVP Traffic
>> Engineering
>> (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are
>> encountering limitations
>> in the ability of implementations to support the growth in
>> the number of LSPs
>> deployed. This document defines two additional RSVP-TE
>> extensions that
>> are intended to reduce the number of messages needed to
>> maintain RSVP-TE
>> soft state in routers and hence allow implementations to
>> support larger
>> scale deployments.
>> ENDS
>> Note: Omit reference from Abstract.
>>
>>
>> [VPB] Fixed in -07
>>
>> s1, para 2: s/under certain/beyond a certain/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s1, para 3: s/makes a set of concrete implementation
>> recommendations/defines
>> two extensions/; s/- push higher/by increasing/; s/maintain
>> LSP state./maintain
>> LSP state by reducing the number of messages needed./
>>
>> Abstract, para 2 and s1, last para: [Omit reference from
>> Abstract]
>> OLD:
>> This document advocates the use of a couple of techniques -
>> "Refresh-
>> Interval Independent RSVP (RI-RSVP)" and "Per-Peer
>> Flow-Control" -
>> for significantly cutting down the amount of processing cycles
>> required to maintain LSP state.
>> NEW:
>> This document defines two RSVP Capabilities [RFC5063] "Refresh-
>> Interval Independent RSVP (RI-RSVP)" and "Per-Peer
>> Flow-Control"
>> that will cut down the number of messsages and processing
>> cycles
>> required to maintain LSP state.
>> ENDS
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s1, last para: Add new penultimate sentence:
>> Note that the "Per-Peer Flow-Control" capability requires
>> the "RI-RSVP"
>> capability as a prerequisite.
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s1, last para: s/RECOMMENDED/recommended/ - this isn't a
>> recommendation about
>> the protocol on the wire.
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> Subdivision of s2: The issues regarding the nature of the
>> document would be
>> helped by altering s2 into four top level sections, thus: s2:
>> Requirement for
>> RFC 2961 Refresh Overhead Reduction Support and Specific
>> Option Choices (from
>> s2.1) s3: Requirement for RFC 5063 Capability Object support
>> (see Minor Issues
>> above) s4: Refresh-Interval Independent RSVP Capability (from
>> s2.3) s5:
>> Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent
>> major sections
>> then renumbered as s6 onwards. References to s2.x will need to
>> be updated
>> throughout.
>>
>>
>> [VPB] We subdivided s2 into 3 top level sections. We did not add a
>> separate section for discussing RFC5063 Capability Object support.
>>
>>
>> s2.1 (would be introduction of new s2):
>> OLD:
>> The implementation recommendations discussed in this
>> section are
>> based on the proposals made in [RFC2961] and act as
>> prerequisites for
>> implementing the techniques discussed in Sections 2.2 and 2.3.
>>
>> NEW:
>> The Capabilities defined in Sections 4 and 5 of this
>> document are based on
>> proposals made in [RFC2961]. Implementations of these
>> Capabilities will
>> need to support the RSVP messages and techniques defined in
>> [RFC2961] as set
>> out in Section 2.1 [was 2.1.1] with
>> some minor modifications and alterations to recommended
>> time intervals and
>> iteration counts as defined in the remainder of this section.
>> ENDS
>>
>>
>> [VPB] Fixed in -07
>>
>> s2.1.1, title and para 1 [will be s2.1]:
>> OLD:
>> 2.1.1. Basic Prerequisites
>>
>> An implementation that supports the techniques discussed in
>> Sections
>> 2.2 and 2.3 must meet certain basic prerequisites.
>> NEW:
>> 2.1. Required Functionality from RFC 2961 to be Implemented
>>
>> An implementation that supports the capabiities discussed
>> in Sections
>> 4 and 5 must provide a large subset of the functionality
>> described
>> in [RFC2961] as follows:
>> ENDS
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.1.2, para 2 [will be s2.2]: s/techniques discussed in
>> Sections 2.2 and
>> 2.3/Capabilities defined in Sections 4 and 5/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.2, para 1: s/improvement on transmission
>> overhead/improvement of
>> transmission overhead/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.2, para 1: s/proposes sufficient recommendations/sets out
>> additional
>> requirements/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.2, last bullet: Add a reference to the proposed new Section
>> 3 that discusses
>> the Capability object.
>>
>>
>> [VPB] Added a direct reference to RFC5063
>>
>>
>> s2.2.1, last para: s/set Refresh-Reduction-Capable bit in
>> common header/set the
>> Refresh-Reduction-Capable bit in the common header/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.3, para 1: s/set of recommendations/functionality/;
>> s/provide/provides/;
>> s/RSVP-TE control plane congestion/a significant portion of
>> the RSVP-TE control
>> message load/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>> s2.3.2: s/MESSAGE ID/MESSAGE_ID/
>>
>>
>> [VPB] Fixed in -07
>>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.proofpoint.com/v2/url?u=https- >3A__www.ietf.org_mailman_ listinfo_teas&d=DwMDaQ&c= HAkYuh63rsuhr6Scbfh0UjBXeMK- ndb3voDTXcWzoCI&r= CFHVfW0WsgxSqM6wTJiWE5evUJAdlU l1fm7E0WVbiS8&m=k7e- cloxf90XW9b_KRgpp7fxJRT4Q-f-_ Nor0jTe8fg&s= g6wdiVKa0BcV5n4De8h3NjtO0hRGaF GruAncUJvpq_k&e=
>>
>>
>>