Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt

From: [email-masked]
Date: Wed, 14 Feb 2018 15:27:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

        Title           : DLEP Latency Range Extension
        Authors         : Bow-Nan Cheng
                          Lou Berger
	Filename        : draft-ietf-manet-dlep-latency-extension-02.txt
	Pages           : 5
	Date            : 2018-02-14

Abstract:
   This document defines an extension to the DLEP protocol to provide
   the range of latency that may be experienced on a link.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02
https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lou Berger <[email-masked]>
Date: Wed, 14 Feb 2018 18:36:47 -0500

Hi,

This version addresses all comments received (to date) during WG LC with 
one exception.  The one exception was a private question/comment on how 
to handle latency that may be queue specific.  As this extension is 
independent of queue definition (which introduced in pause and credit 
extensions) and the same question applies to other link metrics, it was 
my opinion that queue specific metrics are beyond the scope of this 
draft and really warrants a new extension in its own rights.  Given this 
was raised privately during LC and not specifically addressed in this 
version, I thought it important to mention  on list.

All other comments were discussed on list. See below for a link to see 
these diffs.

Lou

On 2/14/2018 6:27 PM, [email-masked] wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 19 Feb 2018 01:23:50 +0200

Hi Lou,

Thanks for your updates. I am sorry that I did not comment on the draft
before, however, this is my thought,

in section 3:

 draft>The Latency Range Data Item serves much the same purpose as the
   Latency Data Item defined in [RFC8175
<https://tools.ietf.org/html/rfc8175>] with the addition of being
   able to communicate the latency range that may be experienced by
   traffic on a link.

AB> IMO, or understanding,  latency range is not one value, but two values,
so how can two values be same in the purpose of one value of latency? maybe
the draft should discuss that for clarification, because I did not
understand.

AB> this draft does not say what will happen to the data item latency of
RFC8175 (type code 16), because in RFC8175 says such messages MUST contain
one value of .... and states the latency item, not the latency-range. Some
sections after 12.6 does not mention the dlep support of such extension
what will happen, so IMO this darft should say how the replacement of
Latency item,

AB> as this draft may need to say that if the extension is supported then
latency range item replaces the latency item, or it may say that the
maximum latency value is used into the latency item value. Not sure which
approach is better.

AB>  My problem in understanding the draft, is that if this draft is
supported as mentioned in section-12.6 in the RFC8175 then it MUST be
contained in that message. So this needs to be said again I think in this
draft (because the draft now says: MAY be carry).

draft>  The Latency Range Data Item MAY be carried in the
   same messages and MUST be processed according to the same rules as
   the Latency Data Item defined in [RFC8175
<https://tools.ietf.org/html/rfc8175>].

AB> same rules, but we have two values, one max-latency and one
min-latency, please clarify,

AB> as mentioned above ''same rules as latency'' but what will happen to
this latency item while it is a MUST in many messages, what will be the
value, but Latency range is a MAY.

AB> so I may suggest the value of the range for the draft's item and that
the latecy iten in rfc8175 contains the max-latency, or any you suggest to
clarify it.

AB> furthermore, the RFC8175 mentions change in metrics what kind of
reaction, so within this draft cases, if the latency was the metric what
value will be used (max, avg, min,...) may need to be specified in the
draft.

Best Regards
AB

On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <[email-masked]> wrote:

> one exception.  The one exception was a private question/comment on how to
> handle latency that may be queue specific.  As this extension is
> extensions) and the same question applies to other link metrics, it was my
> opinion that queue specific metrics are beyond the scope of this draft and
> really warrants a new extension in its own rights.  Given this was raised
> privately during LC and not specifically addressed in this version, I
> thought it important to mention  on list.
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 19 Feb 2018 11:44:45 +0000

Hi Lou,

AB raises a good point about behaviour when one peer does not support
the extension.

In the LID extension draft, I have tried to add normative text that
describes how an implementation supports core DLEP when it does layer-3 
routing.  I think a quick sentence describing how the core Latency
metric should be used when this extension is in use, and not in use
might be beneficial.

Cheers,

Rick

On Mon, 2018-02-19 at 01:23 +0200, Abdussalam Baryun wrote:
> Hi Lou,
> 
> Thanks for your updates. I am sorry that I did not comment on the
> draft before, however, this is my thought,
> 
> in section 3:
> 
>    Latency Data Item defined in [RFC8175] with the addition of being
> AB> IMO, or understanding,  latency range is not one value, but two
> values, so how can two values be same in the purpose of one value of
> latency? maybe the draft should discuss that for clarification,
> because I did not understand.
> 
> 
> AB> this draft does not say what will happen to the data item latency
> of RFC8175 (type code 16), because in RFC8175 says such messages MUST
> contain one value of .... and states the latency item, not the
> latency-range. Some sections after 12.6 does not mention the
> dlep support of such extension what will happen, so IMO this darft
> should say how the replacement of Latency item,
> 
> AB> as this draft may need to say that if the extension is supported
> then latency range item replaces the latency item, or it may say that
> the maximum latency value is used into the latency item value. Not
> sure which approach is better.
> 
> contained in that message. So this needs to be said again I think in
> this draft (because the draft now says: MAY be carry).
> 
>    the Latency Data Item defined in [RFC8175].
> 
> AB> same rules, but we have two values, one max-latency and one min-
> latency, please clarify,
> 
> AB> as mentioned above ''same rules as latency'' but what will happen
> to this latency item while it is a MUST in many messages, what will
> be the value, but Latency range is a MAY.
> 
> AB> so I may suggest the value of the range for the draft's item and
> that the latecy iten in rfc8175 contains the max-latency, or any you
> suggest to clarify it.
> 
> reaction, so within this draft cases, if the latency was the metric
> what value will be used (max, avg, min,...) may need to be specified
> in the draft.
> 
> 
> Best Regards
> AB
> 
> 
> 
> > This version addresses all comments received (to date) during WG LC
> > with one exception.  The one exception was a private
> > question/comment on how to handle latency that may be queue
> > specific.  As this extension is independent of queue definition
> > (which introduced in pause and credit extensions) and the same
> > question applies to other link metrics, it was my opinion that
> > queue specific metrics are beyond the scope of this draft and
> > really warrants a new extension in its own rights.  Given this was
> > raised privately during LC and not specifically addressed in this
> > All other comments were discussed on list. See below for a link to
> > see these diffs.
> > 
> > Lou
> > 
> >

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Feb 2018 17:04:03 -0500

Hi AB,

See below.

> because I did not understand.

So per 8175:

    The Latency Data Item is used to indicate the amount of latency, in
    microseconds, on the link.

so  8175 defines a single point definition of "the amount of latency ... 
on the link" while this draft defines a range for latency "that may be 
experienced by traffic on a link".  Nether say how this is to be used.

I'm not sure what more is to be said on this.  Do you have an proposed 
language?

> should say how the replacement of Latency item,

it's not a replacement.  It is sent in addition.  As is generally the 
case in extension RFCs, if a modification to an existing RFC is not 
stated explicitly, there is no such modification.  I do agree that if 
the new data item were to be sent in place of the old one (a) this 
should be made very explicit and (b) this document would be an update to 
RFC8175.

see the next response
> sure which approach is better.

The document doesn't modify the existing latency data item.

Is it worth adding a sentence to the end of section 2 along the lines of:

Note: the usage of the extension defined in this document does not 
impact processing associated with the Latency Data Item defined in 
Section 13.6 of [rfc8175].

Seems pretty obvious, but also a benign addition
> <https://tools.ietf.org/html/rfc8175>].

can you elaborate on what specific changes you'd like to see?

> min-latency, please clarify,
It's one data item.  RFC8179 defines when and how the data item is sent, 
not how the latency value is set or used.  This is the same for the 
extension.

> to this latency item while it is a MUST in many messages, what will be 
> the value, but Latency range is a MAY.
>
Correct.  An implementation MAY choose to include a Latency Range Data 
Item where it includes a Latency Data Item.

> that the latecy iten in rfc8175 contains the max-latency, or any you 
rfc8175 latency data item is intentionally not impacted by this 
document.  It remains (per 8179)

    The calculation
    of latency is implementation dependent.  For example, the latency may
    be a running average calculated from the internal queuing.

> what value will be used (max, avg, min,...) may need to be specified 

the draft says:

    Maximum Latency:

       A 64-bit unsigned integer, representing the longest transmission
       delay, in microseconds, that a packet encounters as it is
       transmitted over the link.

    Minimum Latency:

       A 64-bit unsigned integer, representing the shortest transmission
       delay, in microseconds, that a packet encounters as it is
       transmitted over the link.

What change/addition would you like to see?

Thanks,
Lou

>
>
> Best Regards
> AB
>
>
>
> On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     This version addresses all comments received (to date) during WG
>     LC with one exception.  The one exception was a private
>     On 2/14/2018 6:27 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>                 Filename        :
>         draft-ietf-manet-dlep-latency-extension-02.txt
>                 Pages           : 5
>                 Date            : 2018-02-14
>
>         Abstract:
>         <https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/>
>
>         <https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02>
>         <https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02>
>
>         <https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02>
>
>
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/manet>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/manet>
>
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Feb 2018 17:07:03 -0500

> AB raises a good point about behaviour when one peer does not support

I think I missed his point on this.  But there is no issue here, per 
standard 8179 processing, if one peer doesn't support the extension it 
isn't used.  What else needs to be said?

> metric should be used when this extension is in use, and not in use
in this extension 8179 behavior continues even when the extension is 
used, so I'm not sure what the concern is for this draft.

Cheers,
Lou

>>>> tools.ietf.org.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 20 Feb 2018 04:19:59 +0200

Hi Lou,

I will try to clarify my concerns below, however, the main issue is the
question: Does the Range Latency item Cannot appear in any message without
Latency item? I prefer not, but please help me to know why if yes.

On Tue, Feb 20, 2018 at 12:04 AM, Lou Berger <[email-masked]> wrote:

>>    Latency Data Item defined in [RFC8175 <https://tools.ietf.org/html/r
>> fc8175>] with the addition of being
>> latency? maybe the draft should discuss that for clarification, because I
>> did not understand.
>>
>>
> So per 8175:
>
>

AB> I think that Latency Range Data Item does not serve the same purpose as
the Latency Data Item, because by requests of the router that data of
Latency is used differently from Latency Range. If you agree, I may suggest
deleting the words ''same purpose'', maybe replaced by '' additional
related information''. It will be good to show/add/write about: the
importance of range because the link may have same latency but different
ranges which affects performance of routing (maybe one line to show that
the range information is related to latency and give it more meaning in
terms of performance).

> it's not a replacement.  It is sent in addition.  As is generally the case
> in extension RFCs, if a modification to an existing RFC is not stated
> explicitly, there is no such modification.

But IMO it is not clear where the Latency Range item operates within 8175,

> I do agree that if the new data item were to be sent in place of the old
> one (a) this should be made very explicit and (b) this document would be an
> update to RFC8175.
>

Yes, ok, so I understand that both items can be independent, (my first read
thought they are dependent some how).

> The document doesn't modify the existing latency data item.

ok,

> Note: the usage of the extension defined in this document does not impact
> processing associated with the Latency Data Item defined in Section 13.6 of
> [rfc8175].
>

I think it will be easier to understand, specially when we say in the draft
they follow same rules in 8175,

so maybe better without section number,

new note> the usage of the extension defined in this document does not
impact processing associated with the Latency Data Item.

>>    the Latency Data Item defined in [RFC8175 <
>> https://tools.ietf.org/html/rfc8175>].
>>
>>

AB> I mean in the draft says MAY be carried in same messages that carry
Latency item. I think this makes the Range item dependent some how. The
question is do you allow one message to carry Range item but without
Latency item. I think you don't mean that, but you mean MAY carry range
item similar to the messages types that MAY carry latency item.

 AB> I prefer that this draft clarifies Range item independently in all
possible  messages as:

*Session Initialization Response Message*   (MUST carry)
*Session Update Message    *(MAY Carry)
*Destination Up Message    *(MAY Carry)
*Destination Announce Response Message   *(MAY Carry)
*Destination Update Message    *(MAY Carry)
*Link Characteristics Response Message    *(SHOULD carry)
(.......may be others ,,,........)

AB> also if the Latency Range is used as a metric, what is the

> Item where it includes a Latency Data Item.

ok

>    be a running average calculated from the internal queuing.

ok

> What change/addition would you like to see?

The addition maybe is what will happen when Range changes, we can say it
will follow similar rules in 8175 of the latency item.

 thank for your explanation,

Best Regards,

AB

---

From: Rick Taylor <[email-masked]>
Date: Tue, 20 Feb 2018 09:44:05 +0000

Hi Lou,

> used, so I'm not sure what the concern is for this draft.

Okay, on re-reading, I'm happy with the text as is.

Cheers,

Rick

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Feb 2018 11:53:04 -0500

> Okay, on re-reading, I'm happy with the text as is.
Thanks, Rick...

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Feb 2018 12:42:04 -0500

Hi AB,

see below.

On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
> Hi Lou,
>
> I will try to clarify my concerns below, however, the main issue is 
> the question: Does the Range Latency item Cannot appear in any message 
> without Latency item?
This document doesn't make this requirement.  Per 8175, there are cases 
where the existing Latency Data Item is optional, so it is possible for 
an implementation to send the extension data item but not a latency data 
item.  This is up to the implementation.

> I prefer not, but please help me to know why if yes.
>

> On Tue, Feb 20, 2018 at 12:04 AM, Lou Berger <[email-masked] 
>         Thanks for your updates. I am sorry that I did not comment on
>         the draft before, however, this is my thought,
>
>         in section 3:
>
>         <https://tools.ietf.org/html/rfc8175
>         <https://tools.ietf.org/html/rfc8175>>] with the addition of being
>         AB> IMO, or understanding,  latency range is not one value,
>         but two values, so how can two values be same in the purpose
>         of one value of latency? maybe the draft should discuss that
>         for clarification, because I did not understand.
>
>
>     So per 8175:
>
>
>     so  8175 defines a single point definition of "the amount of
>     latency ... on the link" while this draft defines a range for
>     latency "that may be experienced by traffic on a link".  Nether
>     say how this is to be used.
>
>     I'm not sure what more is to be said on this.  Do you have an
>     proposed language?
>
>
> AB> I think that Latency Range Data Item does not serve the same 
> purpose as the Latency Data Item, because by requests of the router 
> that data of Latency is used differently from Latency Range.
The text is "much the same"  - if you prefer we can change this to 
"parallel" not that this informative text not normative so no specific 
processing is implied.

>  If you agree,
I don't.  I think you are reading to much into this informative text.

> I may suggest deleting the words ''same purpose'', maybe replaced by 
> '' additional related information''. It will be good to show/add/write 
> about: the importance of range because the link may have same latency 
> but different ranges which affects performance of routing (maybe one 
> line to show that the range information is related to latency and give 
> it more meaning in terms of performance).
>
>
There is no parallel text in 8175 specifically for the latency DI so I'm 
not sure why we'd add it here.

>
>
>         AB> this draft does not say what will happen to the data item
>         latency of RFC8175 (type code 16), because in RFC8175
>         says such messages MUST contain one value of .... and states
>         the latency item, not the latency-range. Some sections after
>         12.6 does not mention the dlep support of such extension what
>         will happen, so IMO this darft should say how the replacement
>         of Latency item,
>
>
>     it's not a replacement.  It is sent in addition.  As is generally
>     the case in extension RFCs, if a modification to an existing RFC
>     is not stated explicitly, there is no such modification. 
>
>
The draft currently says:

      The Latency Range Data Item MAY be carried in the same messages 
... as  the Latency Data Item defined in [RFC8175].

Is this not sufficient?

>  ...

> I think it will be easier to understand, specially when we say in the 
> draft they follow same rules in 8175,
>

sure...

>         AB>  My problem in understanding the draft, is that if this
>         draft is supported as mentioned in section-12.6 in the RFC8175
>         then it MUST be contained in that message. So this needs to be
>         said again I think in this draft (because the draft now says:
>         MAY be carry).
>
>         <https://tools.ietf.org/html/rfc8175
>         <https://tools.ietf.org/html/rfc8175>>].
>
>
> AB> I mean in the draft says MAY be carried in same messages that 
> carry Latency item. I think this makes the Range item dependent some 
> how. The question is do you allow one message to carry Range item but 
> without Latency item.
yes. for example latency is optional in Session Update Message, e.g., 
this covers the case where the range changes but the base latency does 
not.  I don't see any issue with this.

> I think you don't mean that, but you mean MAY carry range item similar 
> to the messages types that MAY carry latency item.
>
>  AB> I prefer that this draft clarifies Range item independently in 
> all possible  messages as:
>
If we had BNF in the document, I agree that the BNF would need to be 
updated.  Since we don't I think this is a bit redundant but of course 
defer to the WG on this.

> AB> also if the Latency Range is used as a metric, what is the
??

...

>         AB> furthermore, the RFC8175 mentions change in metrics what
>         kind of reaction, so within this draft cases, if the latency
>         was the metric what value will be used (max, avg, min,...) may
>         need to be specified in the draft.
>
>
>     the draft says:
>
>        Maximum Latency:
>
> The addition maybe is what will happen when Range changes, we can say 
> it will follow similar rules in 8175 of the latency item.
>
  it says:
  The Latency Range Data Item ...  MUST be processed according to the
   same rules as the Latency Data Item defined in <xref
   target="RFC8175"/>.

Is this not sufficient?

Thanks,
Lou

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 20 Feb 2018 18:47:20 +0000

On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <[email-masked] on behalf of [email-masked]> wrote:

    
    Is this not sufficient?

Perhaps AB is reading this as "if a specific, on-the-wire message has a Latency
Data Item in it, then that particular message is allowed to have a Latency Range
Data Item.  Otherwise, it cannot have a Latency Range Data Item.
AB, is that your interpretation?  If so, then maybe just saying "message types"
instead of "messages" is enough clarification.

David

---

From: Rick Taylor <[email-masked]>
Date: Tue, 20 Feb 2018 21:05:35 +0000

We have been fairly consistent in RFC8175 to refer to DLEP *messages*  I'm not sure adding 'types' helps...

Rick

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: 20 February 2018 18:47
> To: Lou Berger; Abdussalam Baryun
> Cc: manet; [email-masked]
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-
> 02.txt
> 
> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <manet-
> [email-masked] on behalf of [email-masked]> wrote:
> Data Item in it, then that particular message is allowed to have a Latency
> Range Data Item.  Otherwise, it cannot have a Latency Range Data Item.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 20 Feb 2018 16:26:48 -0500

I agree with Rick on adding 'types'. So, I'll propose some text. Maybe this
will help?

"The Latency Range Data Item MAY be carried in any message where the
Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be
carried in addition to, or in lieu of, the Latency Data Item."

Regards,
Stan

>     ... as  the Latency Data Item defined in [RFC8175].

On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <[email-masked]
> wrote:

> >     > But IMO it is not clear where the Latency Range item operates
> within
> >     > 8175,
> >     >
> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Feb 2018 16:29:21 -0500

Stan,

"In lieu" of a mandatory 8175 item is a pretty big change.  I don't think 
we want to go there.  I think the rest of the text is fine.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 20 Feb 2018 16:32:06 -0500

Lou,

> we want to go there.  I think the rest of the text is fine.

Point taken. So, you're good with the second sentence changing to "The
latency Range Data Item MAY be carried in addition to the Latency Data
Item." ??

Regards,
Stan

>> I agree with Rick on adding 'types'. So, I'll propose some text. Maybe
>> this will help?
>>
>> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <rick@tropicalstormsoftware.
>> com> wrote:
>>
>>> > AB, is that your interpretation?  If so, then maybe just saying
>>> "message
>>> > types"

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 02:01:26 +0200

On Tue, Feb 20, 2018 at 8:47 PM, Wiggins, David - 0665 - MITLL <
[email-masked]> wrote:

> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" <
> [email-masked] on behalf of [email-masked]> wrote:
> Range
> AB, is that your interpretation?

Yes but also that we already have for Latency item per message types, MUST,
MAY, SHOULD,

>   If so, then maybe just saying "message types"

That may conflict with the MUST in section 12.6, which is a MUST carry
message type.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 02:26:18 +0200

Hi Stan,

New> The Latency Range Data Item MAY be carried in any message where the
Latency Data Item [RFC8175] is allowed. The Latency Range Data Item MAY be
carried in addition to the Latency Data Item carried in any message."

thanks now it easier to understand,

agreed,

AB

On Tue, Feb 20, 2018 at 11:32 PM, Stan Ratliff <[email-masked]>
wrote:

>>> On Tue, Feb 20, 2018 at 4:05 PM, Rick Taylor <
>>> [email-masked]> wrote:
>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Feb 2018 21:57:41 -0500

How about:

  The Latency Range Data Item MAY be
   carried in any message where the Latency Data Item [RFC8175] is
   allowed and is carried as an additional data item.  When present, the
   Latency Range Data Item MUST be processed according to the same rules
   as the Latency Data Item defined in <xref target="RFC8175"/>.

Lou

On 2/20/2018 4:32 PM, Stan Ratliff wrote:
> Lou,
>
>
> On Tue, Feb 20, 2018 at 4:29 PM, Lou Berger <[email-masked] 
>     "In lieu" of a mandatory 8175 item is a pretty big change.  I
>     don't think we want to go there.  I think the rest of the text is
>     fine.
>
>
>     On February 20, 2018 4:27:16 PM Stan Ratliff
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     I agree with Rick on adding 'types'. So, I'll propose some text.
>>     Maybe this will help?
>>
>>     "The Latency Range Data Item MAY be carried in any message where
>>     the Latency Data Item [RFC8175] is allowed. The Latency Range
>>     Data Item MAY be carried in addition to, or in lieu of, the
>>     Latency Data Item."
>>
>>     Regards,
>>     Stan
>>
>>
>>     <mailto:[email-masked]>> wrote:
>>
>>         We have been fairly consistent in RFC8175 to refer to DLEP
>>         *messages*  I'm not sure adding 'types' helps...
>>
>>         Rick
>>
>>         > From: manet [mailto:[email-masked]
>>         <mailto:[email-masked]>] On Behalf Of Wiggins, David -
>>         > 0665 - MITLL
>>         <mailto:[email-masked]>
>>         > [email-masked] <mailto:[email-masked]> on behalf of
>>         [email-masked] <mailto:[email-masked]>> wrote:
>>         >     > But IMO it is not clear where the Latency Range item
>>         operates within
>>         >     > 8175,
>>         >     >
>>         >
>>         > AB, is that your interpretation? If so, then maybe just
>>         saying "message
>>         > types"

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Feb 2018 14:07:24 -0500

That's reasonable.

Thanks,
Lou

On February 20, 2018 1:47:57 PM "Wiggins, David - 0665 - MITLL" 
<[email-masked]> wrote:

> On 2/20/18, 12:42 PM, "manet on behalf of Lou Berger" 
> <[email-masked] on behalf of [email-masked]> wrote: