Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

[Steve Donovan <[e-mail]>]

Ten is acceptable to me.

Steve


On October 28, 2015 1:36:00 PM "Lee, Jay" <[e-mail]> wrote:

> I also think that we agree on all different points for the finalization, 
> except one point: the value for the default case. Use of the default case 
> as discussed here is rather in the future than in the present for us, so I 
> do not have strong opinion, especially when the default value can be 
> overwritten.
>
> Looking at this objectively and also for the sake of progress, however, it 
> would be prudent to have more than one lower priority cases. In the near 
> future, we may identify additional use cases for lower priority case. Even 
> with one use case identified, this does not necessarily mean one priority 
> level per use case. One use case may require multiple lower priority 
> levels, depending on applications.
>
> Any value from 9 to 12 seems reasonable to me. But, without all use cases 
> identified at the present time, I propose 10 (JJacques' proposal) or 11.
>
> Thanks,
>
> Jay
>
> From: DiME [mailto:[e-mail]] On Behalf Of TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: Monday, October 26, 2015 8:11 AM
> To: [e-mail]
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hi
>
> Please see my comments also in line. I think we are close to finalise our 
> choice on the different points  of this thread
>
> Best regards
>
> JJacques
>
> De : DiME [mailto:[e-mail]] De la part de Lee, Jay
> Envoyé : vendredi 23 octobre 2015 18:57
> À : [e-mail]<mailto:[e-mail]>
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Please see my comments inline.
>
> From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
> Sent: Friday, October 23, 2015 8:02 AM
> To: [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Please see my comments inline.
>
> Steve
> On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:
> See inline
>
> From: DiME [mailto:[e-mail]] On Behalf Of Lee, Jay
> Sent: Friday, October 23, 2015 1:59 AM
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
> <[e-mail]><mailto:[e-mail]>; 
> [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Some further comments from my side:
>
> */ If we need to assign (but not specify) a value to the default case, we 
> need to make it clear that this value can be overwritten by operators, and 
> the value is for some use cases like e.g., equipment having the same value 
> when leaving the factory, so that there would be no misunderstanding.
> mcd- ok
> SRD> I think the current proposed text makes this clear.
> [JL] Agree that the current text is OK especially when we use 'May' in 
> place of 'Should'
> [JJ] OK
> .
>
> */ Since we agree that the default value is per local policy, 'May' is 
> preferred to 'Should' in order not to cause confusion.
> mcd-ok
> SRD> I'm okay with making this a MAY.
> [JL]  Agreed
> [JJ] Also in favor of a MAY
>
> */ For assignment of the default value, I am quite open. But any value 
> between 9 - 12 seems reasonable to me.
> mcd- value should allow for assigning lower values, though a carrier can 
> assign what they want in their network, there needs to be a common meaning 
> at the interconnection point
> SRD> I'm open to any value we decide on.  If there are real use cases that 
> require pushing the default value more to the middle then we should do so.  
> At this point I've heard one use case for the default being something other 
> then the lowest value, thus the proposal to use priority_14 as the default.
> [JJ] Regarding use cases, there may be
>
> -          The case where for "normal" users, an application use the 
> default value for most of its requests except some which have a lower priority
>
> -          the case where besides "normal" user (and high priority users), 
> some users have lower priorities, e.g. Some Machine type Communications 
> (MTC) devices.
> So potentially more than one low priority level would be needed.
> We also have chosen a rather large range of values (16) , allowing 
> flexibility for an operator when they define the number of priorities they 
> want , leaving possibility to future additions. If PRIORITY _14 is the 
> default, it leaves only one lower priority and an operator  cannot add a 
> second one  except by choosing  a default value other than the 14  value.
> Then as, in practice, we may expect a range of low priority smaller than  
> the range of high priority values, this is why the default value was 
> proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal 
> but I am open on another value.
>
> */  Current proposal of 16 values may be enough now, but I am fine with 
> having an extensibility bit to be future proof.
> mcd-ok
> SRD> I don't see a compelling argument to move beyond 16.
> In addition, it isn't clear to me that there is value in defining an 
> extensibility mechanism beyond what is already supported by Diameter.  
> Doing so would add significant complexity to the DRMP mechanism for 
> something that, in my view, has a low probability of being used.
>
> I propose that we not allow extending the DRMP AVP.  Rather we require that 
> any extension require a new AVP.  We can then leave it to the document that 
> proposes the extension to deal with determining whether send the DRMP AVP 
> or the newly defined DRMPv2 AVP.
> [JL] When we proposed that the range be extended to 16, we thought that 
> '16' was large enough and future proof.
> I am okay with having an extensibility bit, if other companies want it. 
> That said, I agree that it has a low probability of being used and added 
> complexity.
> [JJ] JJ I also agree that with 16 values , the offered range is large 
> enough in practice. This point is only to check if it would be easy to do 
> an extension, if we have this requirement in the future.  I agree with 
> Steve that for an extensibility, it will require a new AVP in a new 
> document rather than to define a set of reserved values in the DRMP AVP.  A 
> point is that it will require an additional parsing effort for a node to 
> look for this second AVP even if it is not present most of the time.
>
> */ I am not sure of alternative encoding method (say, +9 to -9 per 
> JJacques' proposal) compared to the current enumerated type of DRMP. It 
> offers a logical way of assigning a value 0 to the default case. But it 
> offers less flexibility to operators, since the default value may not be 
> easily moved to have more higher/lower priority values. Also, we are used 
> to the enumerated type of DRMP and just want to have extension from 5 to 
> 16,  but this may require more deviation from the current design and 
> thinking. For this, I would like to see more on qualitative pros/cons, but, 
> given its little benefit, I am reluctant to accept this alternative.
> SRD> I agree that I don't see value in the +9 to -9 proposal.
> [JL] Agreed
> [J] I presented this second  approach  so to review the possible 
> alternatives as we usually do before selecting the solution, this 
> alternative being already used in a recent RFC.   That being said, I am 
> fine with the enumerated DRMP AVP.
>
> Best regards
>
> JJacques
>
> From: DiME [mailto:[e-mail]] On Behalf Of TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES)
> Sent: Thursday, October 22, 2015 9:39 AM
> To: [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> Hi
>
>
> 1.      PRIORITY_14 as default priority value only allows one level of 
> lower priority (PRIORITY_15)  than the default one; this seems not enough.  
> As use cases, we may have  some Machine type Communication (LTC) devices 
> that may have lower priorities that normal communications without priority. 
>  Even within a Diameter application, some commands may have a lower 
> priority as having a secundary importance.
>
>
> Then which default  value ?
>
> -        it could be PRIORITY_8 in the middle, or if we prefer to have a  
> larger range for higher priorities  than for lower priorities,  the default 
> value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lower 
> priorities than the default one. I would have a preference for this value 
> PRIORITY_10.
>
>
> 2.      About extensibility, the current range of 16 values is already 
> large, but we can have  a reserved value to indicate a further extension. 
> With  an enumerated AVP, there is no possibility to add new values.
>
>
> 3.      I also had a look to some other IETF RFCs addressing priorities 
> that Ken mentioned, so to see if we can benefit from these approaches 
> although done for different contexts.
>
> -        in RFC 4412 (Resource-Priority Header in SIP), wps and ets 
> namespaces have a range of 5 values (0 to 4) with 0 as the highest priority 
>  . But I have not found some indication  (I may have missed it) about the 
> default priority  (I mean a SIP request without  Resource-Priority Header 
> compared  to a SIP request with the Header). Implicitly, I would assume a 
> SIP request without  Resource-Priority Header corresponds to  the lowest 
> priority.  DRMP has a similar approach but with  a larger range and also 
> lower priorities.
>
>
> -        RFC  6710 (priority for SMTP),  uses another encoding of the 
> priority values with an integer between -9 and +9. Lower priorities  are 
> negative an higher priority being positive. When a value increases, it 
> means a higher priority, so the opposite  to DRMP, wps or ets.  But the 
> value 0 is here naturally the default value. So this is an encoding 
> alternative  to the  Enumerated type of the DRMP AVP which avoids the 
> question of the default value.
>
> Note: RFC  6710 also defines some Priority Assignment Policies using a 
> subset of the range.
>
> RFC 6710 has also this guideline :
>    SMTP servers compliant with this specification are not
>    required to support all 19 distinct priority levels (i.e., to treat
>    each priority value as a separate priority), ....  That is, an
>    implementation that only supports N priority levels (where N < 19)
>    will internally round up a syntactically valid priority value that
>    isn't supported to the next higher supported number (or to the
>    highest supported priority, if the value is higher than any supported 
>    priority).
>
> -        This raises the question to have this type of  guideline if 
> considered useful.
>
> So to have your feedback
>
> Best regards
>
> JJacques
>
> De : DiME [mailto:[e-mail]] De la part de DOLLY, MARTIN C
> Envoyé : jeudi 15 octobre 2015 12:33
> À : Lee, Jay; ken carlberg; Steve Donovan
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> A couple thoughts:
>
> 1.      There needs to be a default value defined by the standard, so that 
> equipment have the same value leaving the factory
>
> 2.      This value can be over written based on local policy
>
> 3.      Should have an extensibility bit in order to and more values in the 
> future
>
>
> From: DiME [mailto:[e-mail]] On Behalf Of Lee, Jay
> Sent: Thursday, October 15, 2015 6:16 AM
> To: ken carlberg <[e-mail]<mailto:[e-mail]>>; Steve 
> Donovan <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 
> (drmp): Range of priority levels)
>
> >From my side, some more discussion on Steve's mail may be needed.
>
> 'Should' vs. 'Must':
> One can say that 'Should' is not mandatory. But, in practice, this is a 
> fairly strong statement, and often taken as required. So in this sense, the 
> proposed Note is certainly helpful. But, since we allow operators to 
> override the value, I don't see the reason why we use 'Should'. My 
> suggestion is using 'May'.
>
> PRIORITY_14 priority:
> Since operators can overwrite it, I was not too concerned about it. But if 
> we want to put some value, why '14'? A value lower than 14 is suggested in 
> order to allow more rooms for lower priorities.
>
> Jay
>
> From: DiME [mailto:[e-mail]] On Behalf Of ken carlberg
> Sent: Wednesday, October 14, 2015 8:40 AM
> To: Steve Donovan
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): 
> Range of priority levels)
>
> with respect to the diff-serv example brought up below, some thing to add 
> to that discussion is that it starts off with separate and distinct 
> forwarding behavior whose marked packets provide segmentation of other IP 
> traffic.  The availability of only 6 bits to play with (along with the 
> headaches of transitive trust) also discouraged a line of thought to define 
> end-to-end priority handling versus a per diff-serv domain treatment.  
> RFC-4594 did provide configuration guidelines, but that's a different story.
>
> So back to a couple of ideas to consider.
>
> 1) reserved space.  if we go back to the diff-serv model, the diff-serv 
> working group agreed to set aside a set of values that was reserved for 
> experimental use that could be re-assigned some time in the future.  I'm 
> not suggesting that there should be space set side for experiments, but 
> rather it may be prudent to set aside a reserved set of bits/values so that 
> one doesn't need to define a new AVP if in the future there was a need to 
> define added values beyond the 5 (plus some fudge factor) already mentioned 
> on the list.
>
> 2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized that 
> there can be several sets of users/services that are distinct from each 
> other and yet need to prioritize the traffic.  I bring this up because the 
> draft already identifies two sets of users in sections 5.1 and 5.2 (note: 
> I'm assuming that the latter is aimed at the general public and related to 
> 911/112/999 type calls, which should probably be more specific in the 
> draft).  And there is also the potential of Firstnet users in the US.
>
> As a side note, the distinction and separation of general public and other 
> prioritized users in public phone infrastructures is not exclusive to the 
> US, so the group should not be concerned that this is a US centric effort.  
> There has been GTPS in the UK, as well as other systems in other countries. 
>  The RFC is a bit dated, but feel free to go over rfc-4190 for added 
> background.
>
> and just to reiterate.  I'm not making recommendations in the above - just 
> bringing up some food for thought.
>
> -ken
>
>
> On Oct 14, 2015, at 10:12 AM, Steve Donovan 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> Jay,
>
> The current text is a SHOULD level requirement:
>
>    When there is a mix of transactions specifying priority in request
>    messages and transactions that do not have the priority specified,
>    transactions that do not have a specified priority SHOULD be treated
>    as having the PRIORITY_14 priority.
>
> As such, operators can choose to either not implement a priority or define 
> a different value for their network.
>
> I propose adding the following note after this paragraph to further explain 
> why it is a SHOULD and not a MUST:
>
>       Note: There are scenarios where operators might want to
>       specify a different default value for transactions that do not
>       have an explicit priority.  In this case, the operator defined
>       local policy would override the use of PRIORITY_14 as
>       the default priority.
>
> This leaves the ability for there to be deterministic behavior in Diameter 
> networks that require a default to be defined and are happy with the 
> specified default.  It also gives operators the ability to define a 
> different behavior, most likely with some priority handling/mapping at the 
> edge of the network.
>
> Does this address your concerns?
>
> Regards,
>
> Steve
> On 10/14/15 2:59 AM, Lee, Jay wrote:
> Regarding the issue of whether we need to specify a default value or not, 
> there are pros and cons.
>
> If we specify a value for the default case, we can see the benefits in 
> scenarios between different operator networks, but we take away important 
> options on what operators can do with priority values. On the other hand, 
> if we do not specify the default value, operators may have more options, 
> but there is a question of what to do for this inter-PLMN cases when the 
> networks may use different default values.
>
> In practice, this issue can be addressed at the edge of the network, where 
> Diameter edge agent (DEA) can perform some priority mapping based on 
> bilateral roaming agreement (or SLA (service level agreement)) and other 
> means to insure the proper handling. One may argue that this is not as good 
> as the 'deterministic' case, but operator should be able handle this in a 
> reasonable way. We are fully aware of the fact that, in case of this 
> 'non-deterministic' case, the default value can differ from one operator 
> network to another, and it becomes difficult to guarantee the intended 
> priority handling. Despite this, we still prefer giving options to 
> operators by not specifying the default value.
>
> What we are saying here, however, is not anything new. This is the typical 
> way of handling priority levels. If anything, specifying the default value 
> would be something new. As already mentioned in CT discussion, there is a 
> good example of this - Internet QoS, more specifically DiffServ.
>
> In order to guarantee end-to-end QoS for a specific service, IETF could 
> have specified a value (DiffServ codepoint) for the specific service to 
> have predetermined handling of the traffic, but IETF did not. Instead, 
> DiffServ simply provided a framework for operators to have its own  
> classification and differentiated treatment of the services. To guarantee 
> end-to-end QoS across different networks, then, operators need to do packet 
> inspection, (re)classification, QoS mapping, use of SLA and possibly others 
> at the edge of network (edge router). Therefore, in the DiffServ 
> architecture, intelligence was pushed to the edge of the network. While the 
> end results may not be guaranteed as well as in the case of predetermined 
> handling, it was still a preferred way to give flexibility to operators. My 
> point is that we went through all these troubles to give options of 
> priority handling to operators.
>
> By the way, if we are thinking of possibility of specifying the default 
> value, are we assuming that all operators are interested in this feature 
> (default value in the middle, and high and low priorities at other ends)? 
> Aren't there other operators who are not interested in this feature? I know 
> that at least there is one - Verizon. We have no interest in this feature, 
> and no plan for implementing it. We are OK, if other operators are 
> interested in this feature, and the default value is NOT specified. But we 
> are certainly not happy if DIME is trying to impose this on us.
>
> Jay
>
> From: DiME [mailto:[e-mail]] On Behalf Of 
> [e-mail]<mailto:[e-mail]>
> Sent: Tuesday, October 13, 2015 10:55 AM
> To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
> Cc: DiME; [e-mail]<mailto:[e-mail]>; Pollini, Gregory P
> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Assuming that we define a range of 3 values,
> Assuming that 0 is the lowest priority and 2 the highest,
> Assuming that an agent receives 4 messages at the same time while being in 
> overload control:
> *       1) ULR with Prio-0
> *       2) ULR with Prio-1
> *       3) ULR with Prio-2
> *       4) ULR with no priority AVP
>
> Assuming that the default is locally defined as proposed below,
>
> How do you know that the ULR with priority 2 will be handled with a higher 
> priority  than the request without priority indication?
> And what about ULR message with priority 1 with two levels of highest 
> priority e.g. emergency/Important and government/very important?
>
> Sorry if the answer is obvious but I fail to understand.
>
> Lionel
>
>
>
> De : Shaikh, Viqar A [mailto:[e-mail]]
> Envoyé : samedi 3 octobre 2015 01:21
> À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
> Cc : DiME; [e-mail]<mailto:[e-mail]>; Pollini, Gregory P
> Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Hello all,
>
> Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 
> 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not 
> defined.
>
> Having 15 rather than 16 would be useful from an interworking point of view 
> on Diameter interfaces connecting to the EPS.
>
> Also, my understanding has been that the default value is per local policy.
>
> My 2 cents....
> Viqar
> ________________________________
> From: DiME [[e-mail]<mailto:[e-mail]>] on behalf 
> of [e-mail]<mailto:[e-mail]> 
> [[e-mail]<mailto:[e-mail]>]
> Sent: Thursday, October 01, 2015 3:36 AM
> To: Janet P Gunn; DOLLY, MARTIN C
> Cc: DiME; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
> Hi,
>
> I think that the case "no Priority indication in request" is the default 
> situation today.
> So if we agree that it should be possible to explicitly indicate a request 
> with a lower priority, we should divide the range of priority values in 
> three sub-ranges: [lower priorities][no priority indication][higher 
> priorities], e.g. with 17 values: [0-7][8][9-16].
> If any operator can freely fix the default value, there would be no way to 
> ensure the sender that a request with a specific priority value (e.g. 6) 
> will be handled with a lower or higher priority than a request with no 
> priority indication.
>
> Therefore, for a deterministic handling mechanism, I think that it is then 
> more relevant to define a standard value for the default value.
>
> Regards,
>
> Lionel
>
>
> De : DiME [mailto:[e-mail]] De la part de Janet P Gunn
> Envoyé : mercredi 30 septembre 2015 22:53
> À : DOLLY, MARTIN C
> Cc : DiME; [e-mail]<mailto:[e-mail]>
> Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels
>
> Same here.  The "default priority" should be a matter of local policy.
>
> Janet
>
> This is a PRIVATE message. If you are not the intended recipient, please 
> delete without copying and kindly advise us by e-mail of the mistake in 
> delivery. NOTE: Regardless of content, this e-mail shall not operate to 
> bind CSC to any order or other contract unless pursuant to explicit written 
> agreement or government initiative expressly permitting the use of e-mail 
> for such purpose.
>
>
>
> From:        "DOLLY, MARTIN C" <[e-mail]<mailto:[e-mail]>>
> To:        Steve Donovan 
> <[e-mail]<mailto:[e-mail]>>, 
> "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
> Date:        09/30/2015 04:40 PM
> Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
> Sent by:        "DiME" <[e-mail]<mailto:[e-mail]>>
> ________________________________
>
>
>
> Me as well
>
> From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
> Sent: Wednesday, September 30, 2015 4:38 PM
> To: [e-mail]<mailto:[e-mail]>
> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
>
> I'm okay with Jay's proposal on not specifying a default value.
>
> Steve
> On 9/30/15 3:27 PM, Lee, Jay wrote:
> Hi Steve and all,
>
> For the first proposal, as I indicated, I support increasing the number of 
> priority levels up to 16.
>
> I am also fine with the second proposal. My question is: do we need to 
> mandate this feature, as individual operators have different situations? 
> Perhaps some flexibility should be allowed? Instead of mandating it, we can 
> include the statement that when there is no DRMP AVP, this correspond to 
> 'normal traffic' without a particular high or low priority. Then each 
> operator can map this default to a value (e.g., 8 or something else) that 
> they feel appropriate.
>
> Thanks,
>
> Jay
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>  _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>
> _______________________________________________
>
> DiME mailing list
>
> [e-mail]<mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
> _______________________________________________
>
> DiME mailing list
>
> [e-mail]<mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
> ----------
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>