Subject: [manet] DLEP-09

From: "Ratliff, Stanley" <[email-masked]>
Date: Fri, 17 Apr 2015 12:59:52 +0000

Hello Working Group,

DLEP-09 was posted yesterday, and contains the fixes for issues brought up in reviews prior to IETF 92.

With DLEP-09, the authors formally request a 2-week Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due by May 1, 2015.

Regards,
Stan

________________________________
Stan Ratliff  |  Architect, Applied Research
VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA
T: +1 703 544-8520  |  F: +1 222 123-4567
[email-masked]<mailto:[email-masked]>  |  www.idirect.net<http://www.idirect.net>
Connect with iDirect: Twitter.com/iDirect<https://twitter.com/idirect>  |  Facebook.com/iDirect<https://www.facebook.com/idirect>

Advancing a Connected World

---

From: Justin Dean <[email-masked]>
Date: Fri, 17 Apr 2015 16:28:51 -0400

I've looked over the document and feel that the changes are minor enough to
continue the last call (due to the previous mix up).  But due to said mix
up, and the fact that the document has just been updated, I feel a 3 week
last call is more appropriate at this point.  More feedback from more eyes
on the document will result in a better document.

DLEP-09 last call to end on May 8th.

Also a heads up that we are planning virtual interim meetings using the
ietf's webex.  The dates of those meetings will be posted to the list soon.

Justin Dean

On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley <[email-masked]>
wrote:

> With DLEP-09, the authors formally request a 2-week Working Group Last
> Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due
> by May 1, 2015.
>
>
>
> Regards,
> Stan
>
>
>  ------------------------------
>
> *Stan Ratliff  *|  Architect, Applied Research
>
> *VT iDirect  *|  13861 Sunrise Valley Drive, Suite 300, Herndon, VA
> 20171, USA
>
> [email-masked]  |  www.idirect.net
>
> *Connect with iDirect: *Twitter.com/iDirect <https://twitter.com/idirect>
> |  Facebook.com/iDirect <https://www.facebook.com/idirect>
>
>
>
>  *Advancing a Connected World*
>
>
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Fri, 17 Apr 2015 20:40:01 +0000

Hello working group –

I want to solicit other opinions on this issue. To be honest, Justin and I are not in agreement. I’m of the opinion that, if we extend the WGLC period on DLEP to 3-weeks, we should make it standing practice to extend the WGLC to a 3-week period on *all* subsequent work done by MANET.

Opinions?

Regards,
Stan

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: Friday, April 17, 2015 4:29 PM
To: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] DLEP-09

I've looked over the document and feel that the changes are minor enough to continue the last call (due to the previous mix up).  But due to said mix up, and the fact that the document has just been updated, I feel a 3 week last call is more appropriate at this point.  More feedback from more eyes on the document will result in a better document.

Also a heads up that we are planning virtual interim meetings using the ietf's webex.  The dates of those meetings will be posted to the list soon.
Justin Dean

On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
Hello Working Group,

Regards,
Stan

T: +1 703 544-8520<tel:%2B1%20703%20544-8520>  |  F: +1 222 123-4567

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 17 Apr 2015 22:10:19 +0100

WGLCs are naturally variable, depending on the nature of the document, it's not one size fits all. We've had 2 and 4 week WGLCs in the past. From my recollection (subject to correction) of the lengths set in the past, and that this is not a trivial document, 4 weeks rather than 2 weeks would have fitted precedent. This is not an extension to 3 weeks.

Note, I'm not disputing 3 weeks, I'm disputing this sets any sort of precedent. And Justin is the neutral WG chair here.

(Just found the WGLC announcement of OLSRv2. You set that at 30 days.)

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 17 Apr 2015, at 21:40, Ratliff, Stanley <[email-masked]> wrote:
> 
> Hello working group –
>  
> On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley <[email-masked]> wrote:
> Hello Working Group,
>  
> Connect with iDirect: Twitter.com/iDirect  |  Facebook.com/iDirect
>

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 17 Apr 2015 14:24:57 -0700

Stan,

I agree with Justin's request for a longer WGLC, but I don't believe that
this needs to be a standing practice for all future documents. DLEP is a
long document and has changed very recently. Justin is not an author of the
document.

Best regards
Ulrich

On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, Stanley <[email-masked]>
wrote:

>  Hello working group –
>
>
>
> I want to solicit other opinions on this issue. To be honest, Justin and I
> are not in agreement. I’m of the opinion that, if we extend the WGLC period
> on DLEP to 3-weeks, we should make it standing practice to extend the WGLC
> to a 3-week period on **all** subsequent work done by MANET.
>
>
>
> Opinions?
>
>
> Regards,
> Stan
>
>
>
>
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* Friday, April 17, 2015 4:29 PM
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] DLEP-09
>
>
>
> I've looked over the document and feel that the changes are minor enough
> to continue the last call (due to the previous mix up).  But due to said
> mix up, and the fact that the document has just been updated, I feel a 3
> week last call is more appropriate at this point.  More feedback from more
> eyes on the document will result in a better document.
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 20 Apr 2015 12:49:24 +0200

> up in reviews prior to IETF 92.

I just finished reading the DLEP-09 document and I like the improvements
since version -07.

There are three things I noticed while reading.

Section 4.1:
- Latency is mandatory... is it okay to say "Latency 0" if you don't
know or cannot calculate because of CSMA/CA? If yes we maybe should say
that in the text.

Section 4.5:
- Text malformed: "If [Heartbeat signals]#..."

Section 7.9:
- didn't we talked about allowing EUI-64 addresses here? I am not sure.
Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64
tech like 802.15.4

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: John Dowdell <[email-masked]>
Date: Mon, 20 Apr 2015 11:50:49 +0100

Justin/Stan

I'd agree with the bigger document/longer WGLC. I can see that we'd need 
a fair chunk of time when we get to AODVv2 last call; we are improving 
readability (and hence reviewability, if that's a word, my spell checker 
thinks not), but I can see that they'd easily need more than 14 days to 
get their head around it from a standing start.

However, DLEP has been around for some five years in various guises. We 
know there are lots of sleeping reviewers out there, because we meet 
them all the time; be good to get some views from them.

Regards
John

On 17/04/15 22:24, Ulrich Herberg wrote:
> Stan,
>
> I agree with Justin's request for a longer WGLC, but I don't believe 
> that this needs to be a standing practice for all future documents. 
> DLEP is a long document and has changed very recently. Justin is not 
> an author of the document.
>
> Best regards
> Ulrich
>
> On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, Stanley 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello working group –
>
>     I want to solicit other opinions on this issue. To be honest,
>     Justin and I are not in agreement. I’m of the opinion that, if we
>     extend the WGLC period on DLEP to 3-weeks, we should make it
>     standing practice to extend the WGLC to a 3-week period on **all**
>     subsequent work done by MANET.
>
>     Opinions?
>
>
>     Regards,
>     Stan
>
>     *From:*manet [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Justin Dean
>     I've looked over the document and feel that the changes are minor
>     enough to continue the last call (due to the previous mix up). 
>     But due to said mix up, and the fact that the document has just
>     been updated, I feel a 3 week last call is more appropriate at
>     this point.  More feedback from more eyes on the document will
>     result in a better document.
>
>     Also a heads up that we are planning virtual interim meetings
>     using the ietf's webex.  The dates of those meetings will be
>     posted to the list soon.
>
>     Justin Dean
>
>     On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hello Working Group,
>
>         DLEP-09 was posted yesterday, and contains the fixes for
>         issues brought up in reviews prior to IETF 92.
>
>         With DLEP-09, the authors formally request a 2-week Working
>         Group Last Call (WGLC). If the 2-week WGLC is granted, Last
>         call comments would be due by May 1, 2015.
>
>         Regards,
>         Stan
>
>         ------------------------------------------------------------------------
>
>         *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon,
>         VA 20171, USA
>
>         T: +1 703 544-8520 <tel:%2B1%20703%20544-8520>  |  F: +1 222
>         123-4567
>
>         [email-masked] <mailto:[email-masked]>__|
>         www.idirect.net <http://www.idirect.net>
>
>         *Connect with iDirect: *Twitter.com/iDirect
>         <https://twitter.com/idirect>__| Facebook.com/iDirect
>         <https://www.facebook.com/idirect>
>
>         **
>
>         **
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 20 Apr 2015 12:34:34 +0000

Comments inline...

> There are three things I noticed while reading.

There's at least one other change you missed ;)

> know or cannot calculate because of CSMA/CA? If yes we maybe should say

Hmmm... I don't like the idea of latency 0, but I agree that there is a 
potential problem with 'currently unmeasurable' latency.  Thoughts anyone?

> - Text malformed: "If [Heartbeat signals]#..."

Bother!  Fixed in my copy now.

> Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64

There is no real reason that a MAC address MUST have Length 6.  Perhaps 
there should be some extra text here mentioning EUI-64 addresses are 
perfectly valid.  The only restriction is that all MAC addresses in a 
session should be of the same length.

Rick

---

From: John Dowdell <[email-masked]>
Date: Mon, 20 Apr 2015 13:55:32 +0100

> potential problem with 'currently unmeasurable' latency.  Thoughts anyone?
I'd prefer it if the radio can return a rough order magnitude response 
on latency, just so the link can be characterised against the other 
local modems that do return latency figures. Similarly with modems that 
find it hard to discuss bandwidth. However such a response might need an 
indication that this is a guide figure, but given that functions that 
feed off DLEP seem (in my personal view) to work better with regularly 
updated rough estimates rather than precision responses, I don't think 
this will be necessary.

John

---

From: Henning Rogge <[email-masked]>
Date: Mon, 20 Apr 2015 14:55:24 +0200

Section7.9:

> Data Item Type:  TBD
> Length:  6

Maybe this should be replaced with "length: 6 or 8" ?

Henning

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 20 Apr 2015 13:26:29 +0000

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of John Dowdell
> Sent: Monday, April 20, 2015 8:56 AM
> To: [email-masked]
> >> I just finished reading the DLEP-09 document and I like the
> >> improvements since version -07.
> >>
> >> know or cannot calculate because of CSMA/CA? If yes we maybe should
> >> say that in the text.
> > Hmmm... I don't like the idea of latency 0, but I agree that there is
> > a potential problem with 'currently unmeasurable' latency.  Thoughts
> anyone?

My initial thought is "This is a fight/discussion that we had 2 YEARS ago; I thought we had actually settled it." 

> I'd prefer it if the radio can return a rough order magnitude response on
> latency, just so the link can be characterised against the other local modems
> that do return latency figures. Similarly with modems that find it hard to
> discuss bandwidth. However such a response might need an indication that
> this is a guide figure, but given that functions that feed off DLEP seem (in my
> personal view) to work better with regularly updated rough estimates rather
> than precision responses, I don't think this will be necessary.

So, I read that as "If you can't actually calculate latency, then give us your best guess..." ?????  ;-)

Having gotten the snark out of my system (for now), I'd say the "real" answer is: 
The only way to "fix" this is to make latency optional. If you can't (or won't) calculate latency, then don't send it. Although an implementation could choose a "default latency" that is sent in at the peer-level. This "default" latency would have to be replicated into all sessions created through the radio. If the radio subsequently can't (won't) calculate latency, then the provided "default" gets used... and before you ask, "heuristics for choosing an appropriate default latency value are left to the implementation".

Regards,
Stan

> >> Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with
> >> EUI-64 tech like 802.15.4
> > There is no real reason that a MAC address MUST have Length 6.
> > Perhaps there should be some extra text here mentioning EUI-64
> > addresses are perfectly valid.  The only restriction is that all MAC
> > addresses in a session should be of the same length.
> >
> > Rick
> >

---

From: Henning Rogge <[email-masked]>
Date: Mon, 20 Apr 2015 15:35:01 +0200

> My initial thought is "This is a fight/discussion that we had 2 YEARS ago; I thought we had actually settled it."

I thought the same...

> Having gotten the snark out of my system (for now),
Sorry for this... most likely it got drowned out by more important
DLEP discussions.

> I'd say the "real" answer is:

I would be okay with both... either we say "give it a best guess if
you cannot measure/calculate/know it" or we make it optional.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Mon, 20 Apr 2015 14:42:53 +0000

> you cannot measure/calculate/know it" or we make it optional.

Having produced blood, sweat and tears to remove the 
'mandatory/optional' mess we got into with previous drafts, I would be 
really keen to keep Latency as mandatory, and if it can't be calculated 
by the implementation then it must be set with a value from a 'best 
guestimate' or an implementation configured option, and (probably) 
announced at the peer level.

Rick

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 20 Apr 2015 16:48:18 +0200

On Fri, Apr 17, 2015 at 10:28 PM, Justin Dean <[email-masked]> wrote:

> to continue the last call (due to the previous mix up).
>

Just quick look in the beginning. The abstract does not look like an
abstract of the protocol, it seems like an introduction, I suggest that we
look into amending/editing the abstract.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 20 Apr 2015 16:53:29 +0200

On Mon, Apr 20, 2015 at 3:35 PM, Henning Rogge <[email-masked]> wrote:

> > The only way to "fix" this is to make latency optional. If you can't (or
> won't) calculate latency, then don't send it. Although an implementation
> could choose a "default latency" that is sent in at the peer-level. This
> "default" latency would have to be replicated into all sessions created
> through the radio. If the radio subsequently can't (won't) calculate
> latency, then the provided "default" gets used... and before you ask,
> "heuristics for choosing an appropriate default latency value are left to
> the implementation".
>

IMO, if the above is ok then  latency to be optional is the best decision
for the protocol.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 20 Apr 2015 17:03:42 +0200

I think sometimes using optional items is more flexible than mandatory and
gives advantages to the protocol. It should not create any problem in the
protocol operations, because the protocol does not use it, but the router
can use that information or leave it. Making it mandatory may mean that the
protocol will be affected if not have its value but the protocol is not
affected.

AB

On Mon, Apr 20, 2015 at 4:42 PM, Rick Taylor <[email-masked]

> >> My initial thought is "This is a fight/discussion that we had 2 YEARS
> ago; I thought we had actually settled it."
> >
> > I thought the same...
> >
> on
> >> The only way to "fix" this is to make latency optional. If you can't
> (or won't) calculate latency, then don't send it. Although an
> implementation could choose a "default latency" that is sent in at the
> peer-level. This "default" latency would have to be replicated into all
> sessions created through the radio. If the radio subsequently can't (won't)
> calculate latency, then the provided "default" gets used... and before you
> ask, "heuristics for choosing an appropriate default latency value are left
> to the implementation".
> >

---

From: John Dowdell <[email-masked]>
Date: Tue, 21 Apr 2015 13:24:32 +0100

AB, that's not the point. In order for DLEP to be useful to upstream 
protocols, it has to be relied upon to deliver something. At the moment, 
the something includes bandwidth (in its various forms) and latency. If 
you don't know the modem's best guess about those, it's very difficult 
for DLEP to be useful in calculating forwarding decisions. Essentially 
you are back to routing in the dark.

If a modem cannot, for whatever reasons, report either bandwidth or 
latency, the network implementers have to administratively add a figure, 
based on how they think the link performs. DLEP is very useful in 
creating plug and play networks, so if the modem can report a rough 
order of magnitude, that is so much better than no guess at all.

John

On 20/04/15 16:03, Abdussalam Baryun wrote:
> I think sometimes using optional items is more flexible than mandatory 
> and gives advantages to the protocol. It should not create any problem 
> in the protocol operations, because the protocol does not use it, 
> but the router can use that information or leave it. Making it 
> mandatory may mean that the protocol will be affected if not have its 
> value but the protocol is not affected.
>
> AB
>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 21 Apr 2015 13:18:36 +0000

John, 

I think we've reached rough consensus that text should be added to say implementations MUST provide at a minimum a reasonable representation of latency during the Peer Init/Peer Init ACK sequence. This "reasonable representation" represents the "best guess" you are referring to, and would under the existing document be used as the default value for all destinations reachable via the radio peer. 

Regards,
Stan

> Sent: Tuesday, April 21, 2015 8:25 AM
> To: [email-masked]
> AB, that's not the point. In order for DLEP to be useful to upstream protocols,
> it has to be relied upon to deliver something. At the moment, the something
> includes bandwidth (in its various forms) and latency. If you don't know the
> modem's best guess about those, it's very difficult for DLEP to be useful in
> calculating forwarding decisions. Essentially you are back to routing in the
> dark.
> 
> based on how they think the link performs. DLEP is very useful in creating
> plug and play networks, so if the modem can report a rough order of
> magnitude, that is so much better than no guess at all.
> 
> John
> 
> > in the protocol operations, because the protocol does not use it, but
> > the router can use that information or leave it. Making it mandatory
> > may mean that the protocol will be affected if not have its value but
> > the protocol is not affected.
> >
> > AB
> >
>

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 22 Apr 2015 11:49:13 +0100

Hi Stan, hi all,

A few comments on DLEP-09:

When DLEP supplies both MAC and IP address of a destination, would it
create ARP entries? This is mentioned in Section 2 Assumptions and also in
6.9 Destination Up, where it specifically says "reducing the need for the
receiver to probe for any address".

Also in Section 2 Assumptions, you have a statement that any signals not
understood should result in session termination, but that data items that
are not understood should be ignored. Compare with Section 5 DLEP Message
Processing, where it says that unrecognized, invalid or disallowed data
items also force termination, and 6.4 which says that any metric data item
which is not expected causes termination. I guess the Assumptions just
needs updating?

In 3.3 Experimental Signals and Data Items, it becomes clear by the end of
this section that we have an Experimental Definition which is a set of
signals and data items. I would suggest making this clearer from the start
by rewriting the second sentence "The intent is to allow for
experimentation with a set of new signals and/or data items,"... but maybe
I am being too picky!

In Section 4 Metrics, in the last paragraph, you state that algorithms for
utilizing dual context metrics is out of scope. Then in Section 4.5 and 6.5
you say that metrics supplied in Peer signals MUST be set for all
destinations.

In Section 4 which is titled Metrics, you then have subsections 4.2 - 4.5
which are about session flow. Should these be a separate Section between 4
and 5? Also, you have subsections for discovery and common flow but not for
termination. If you did, it might be a nice place to collect the
information about termination due to unrecognized/invalid signals and data
items, plus would make this "session flow" section more complete.

In 4.5 you have "[Heartbeat signals]#(sig_heartbeat)".

In 5.1 you have a typo - "bu" instead of "by".

In 6.5 you say that modems that don't track layer 3 addresses SHOULD
silently parse and ignore the Peer Update, then the final sentence in the
section says a Peer Update MUST be acknowledged by a Peer Update ACK. Also,
if a modem does not support layer 3 address tracking, why wouldn't it just
send back an ACK with a non-zero status code? Then the router doesnt have
to "determine" that it isnt supported, it can be told.

In 6.4 you have an extra space between "in- session".

In 6.10, 6.12, if the ACK shows that the signal was not successfully
processed, what then?

In 7.1 the first sentence should end after "signals".

In 7.11 IPv6 Address, one of the sentences says IPv4 instead.

In 7.12 and 7.13 for the attached subnet data items, I wondered if there
would be an impact which needs considering, since to withdraw this subnet
you need to send a Destination Down. If this impacts on a routing process
when the destination itself is not down but needs to be reported down in
order to remove the attached subnet information, is this acceptable? Is it
"up to the implementation" to handle this case gracefully?

In 7.16, 7.17 and 7.18, I like that you have separated the description for
the data item's use in the Link Characteristic Request signal, however you
now dont have the matching statement that it MAY appear in Link
Characteristic Request, which I think should be there.

Kind regards,
Victoria.

---

From: Vigneswaran R <[email-masked]>
Date: Wed, 29 Apr 2015 12:45:59 +0530

Adding my observations inline...

On 04/22/2015 04:19 PM, Victoria Mercieca wrote:
> create ARP entries? This is mentioned in Section 2 Assumptions and 
> also in 6.9 Destination Up, where it specifically says "reducing the 
> need for the receiver to probe for any address".
>
> Also in Section 2 Assumptions, you have a statement that any signals 
> not understood should result in session termination, but that data 
> items that are not understood should be ignored. Compare with Section 
> 5 DLEP Message Processing, where it says that unrecognized, invalid or 
> disallowed data items also force termination, and 6.4 which says that 
> any metric data item which is not expected causes termination. I guess 
> the Assumptions just needs updating?
>
> In 3.3 Experimental Signals and Data Items, it becomes clear by the 
> end of this section that we have an Experimental Definition which is a 
> set of signals and data items. I would suggest making this clearer 
> from the start by rewriting the second sentence "The intent is to 
> allow for experimentation with a set of new signals and/or data 
> items,"... but maybe I am being too picky!
>
> In Section 4 Metrics, in the last paragraph, you state that algorithms 
> for utilizing dual context metrics is out of scope. Then in Section 
> 4.5 and 6.5 you say that metrics supplied in Peer signals MUST be set 
> for all destinations.
>
> In Section 4 which is titled Metrics, you then have subsections 4.2 - 
> 4.5 which are about session flow. Should these be a separate Section 
> between 4 and 5? Also, you have subsections for discovery and common 
> flow but not for termination. If you did, it might be a nice place to 
> collect the information about termination due to unrecognized/invalid 
> signals and data items, plus would make this "session flow" section 
> more complete.
>
> silently parse and ignore the Peer Update, then the final sentence in 
> the section says a Peer Update MUST be acknowledged by a Peer Update 
> ACK. Also, if a modem does not support layer 3 address tracking, why 
> wouldn't it just send back an ACK with a non-zero status code? Then 
> the router doesnt have to "determine" that it isnt supported, it can 
> be told.
>

Similar is the case with 7.4 (the line above the packet diagram).

> In 7.12 and 7.13 for the attached subnet data items, I wondered if 
> there would be an impact which needs considering, since to withdraw 
> this subnet you need to send a Destination Down. If this impacts on a 
> routing process when the destination itself is not down but needs to 
> be reported down in order to remove the attached subnet information, 
> is this acceptable? Is it "up to the implementation" to handle this 
> case gracefully?
>
> In 7.16, 7.17 and 7.18, I like that you have separated the description 
> for the data item's use in the Link Characteristic Request signal, 
> however you now dont have the matching statement that it MAY appear in 
> Link Characteristic Request, which I think should be there.

In 7.18, the words "data item" repeated twice in the first line.

In 8.2.3,

"If the corresponding Destination Up signal (Section 6.9) for this 
session did NOT contain a Credit Window Status data item, indicating 
that credits are to be used on the session, then the Credit Request data 
item MUST be silently dropped by the receiver."

However it seems, only 'Credit Grant' data item is valid in the 
'Destination Up' signal (in credit windowing context).

So, do we mean,

"If the corresponding Destination Up signal (Section 6.9) for this 
session did NOT contain a *Credit Grant* data item, indicating that 
credits are *NOT* to be used on the session, then the Credit Request 
data item MUST be silently dropped by the receiver."

Regards,
Vignesh

>
>
>
> Kind regards,
> Victoria.
>
> On Fri, Apr 17, 2015 at 1:59 PM, Ratliff, Stanley 
>     With DLEP-09, the authors formally request a 2-week Working Group
>     Last Call (WGLC). If the 2-week WGLC is granted, Last call
>     comments would be due by May 1, 2015.
>
>     Regards,
>     Stan
>
>     T: +1 703 544-8520 <tel:%2B1%20703%20544-8520>  |  F: +1 222 123-4567
>
>     <https://www.facebook.com/idirect>**
>
>     **
>
>     **
>