Subject: [manet] DLEP-17 and RtgDir review of draft-ietf-manet-dlep-14

From: Lou Berger <[email-masked]>
Date: Tue, 1 Dec 2015 18:35:32 -0500

Hello,

I have finally had a chance to review this draft and agree that DLEP-17
is a big step forward, but I still have some comments. Before starting
any new discussions I wanted to revisit my original review, to confirm
my view of status.  Please let me know if you disagree.

On 6/8/2015 3:10 PM, Lou Berger wrote:
> ...
>
> Major Issues:
>
>     - The length field of the generic data item (i.e., TLV) is only 8
>       bits.  While 255 bytes (assuming that this is the unit of measure,
>       which BTW isn't specified) is big enough today, allowing for
>       larger will greatly simplify things when 255 isn't enough. --
>       We've run into this in RSVP and it's a real pain.
Fixed.

>     - Version number is currently defined as a data item.  This means a
>       signal (i.e., message) needs to be potentially fully parsed to
>       discover what version is being used.  This precludes basic format
>       changes to the protocol.  Perhaps the Discovery and Init Signals
>       should be special cased to include version in their formats.  (And
>       shorten version to 8 bits from 32, as mentioned below).
Fixed.

>     - The document references, but does not define, 'in-session' and
>       'discovery' states.  These either need to be formally defined or
>       removed.  BTW we had exactly the same issue with LMP (RFC4204) and
>       ended up adding section 11 (FSMs) at a pretty late stage of the
>       process.

Definitely improved.  I still think there would be value in providing
the state diagram.  This would help clarify permitted/missing
transitions and events.  (For example TCP closes are not called out.)

>     - TCP session management is not defined, nor is the relationship
>       with TCP and DLEP sessions fully defined.  For example:
>
>       o Closing the TCP session is only mentioned in one place and in a
>         way that is inconsistent with the expected protocol behavior
>         (close TCP before ACK is received).
>
>       o What happens when a DLEP session is terminated, can the TCP
>         session be reused or must it be closed too?

Think this is mostly okay, i.e., Major item is close, but there are
still some minor issues, e.g., specifying behavior of an unexpected TCP
close.

>
>     - There is no transaction model defined.  For example, it's
>       completely unclear if only one unacknowledged Signal allowed at a
>       time, or perhaps just one per signal type is allowed, or perhaps
>       there are no restrictions.  This needs to be explicit.  

This is improved, but is still a bit unclear.  As I read section 4.1,
parallel 'destination-specific' transactions are now allowed. Also in
parallel with this,  a single 'Session Request' transaction is
permitted.  Looking at table 1, I think it's clear which are session
messages (1-8) and which are destination messages (9-13), but it is
unclear which category Link Characteristics fall into.  More
significantly, it's unclear how new messages should be handled.

One related point, but is really just a comment on the new error
handling text in section 4.1.  The last paragraphs state that response
failures will be detected by heartbeat failures.  This works for
complete failures, but won't detect the case of failed 'destination'
transaction.

>
>     - What is the purpose of retries and timeouts over TCP?  Retries
>       aren't needed over TCPs and it's unclear whey they are being used.
Fixed.

>     - The higher level implications of ACKs, over TCP, isn't really
>       clear.  It seems ACKs are defined for multiple purposes: reliable
>       transport, transaction acknowledgment and transaction results. Of
>       course the first isn't needed, and implications of the others
>       should be clear.  For example, in section 7.10, why would there be
>       a retry when receiving a Destination Up ACK signal indicating an
>       error?

Fixed, although the text still refers to responses as acknowledging
their corresponding messages which is a bit misleading.  Better to just
say that a response is triggered by the corresponding message.

>     - There is no discussion on scaling considerations. Are there really
>       none?  For example, how often might be appropriate to issue/limit
>       Peer Updates based to changes in link quality, or how to handle
>       the case where a large number (all or most) of destinations go
>       down.

Improved. There is now an informative section (7) which has some some
conformance statements, but no defined mechanisms.  I'd prefer to see
some mechanisms, but also understand that this may be FFS.

>     - There are 13 places where the protocol allows implementation to
>       define their own 'heuristics'.  Some of these seem unnecessary due
>       to the TCP point raised above, but any that remain in the protocol
>       should be fully specified to ensure predictable/consistent
>       behavior from implementations.

Much improved. It's down to 4 (one of which, in section 5.1) partially
conflicts with other text. Again, I think these should be fully specified.

>
>     - Data Items are defined for "Extensions" and "Experimental
>       Definition" (Sections 8.7 and 8.8).  Both seem to support for
>       optional mechanisms, but the former uses assigned numeric values,
>       why the latter uses UTF-8 strings.
>       o What, if any, is the intended distinction/relationship between
>         these?
>       o How does an "Experimental Definition" become standardized?

Again, much improved.  I'll start a separate thread related to the new
mechanism.

>     - Sections 8.19 and 8.20 define "Resources" related Data Items.  The
>       definition related to these basically says a resources is "An
>       8-bit integer percentage, 0-100, representing the amount of
>       resources allocated to receiving|transmitting data.".  If I were
>       implementing this protocol, I'd have no idea how to produce,
>       update or use this information.  I think there is some missing
>       informative and normative (RFC 2119) text related to these
>       formats.

Unless I missed it, no change.

The basic point is that the document should state what are interoperable
implementations supposed to do with this parameter.

>
>     - Sections 8.21 and 8.22 (Relative Link Quality) have a similar
>       problem of being under described, in particular it's unclear if
>       there's a meaningful, non-proprietary definition for link quality
>       that an implementation is to act on or if the passed value is just
>       passed for as monitoring information.  Either way, this needs to
>       be clarified.
Unless I missed it, no change.

The basic point is that the document should state what are interoperable
implementations supposed to do with this parameter.

>
>     - Section 9 defines a "credit-windowing scheme analogous to the one
>       documented in [RFC5578]". It describes how credits are exchanged,
>       but it provides zero definition on the implications or use of
>       credits relative to the data plane.   

moved to it's own document.

>     - Multiple ways to implement the same function are allowed, e.g.,
>       optional presence of Status, Interval and TCP port.  Generally
>       allowing such complicates testing and leads to interoperability
>       issues.  The document should pick one way and require it.

This issue is still there WRT Status and specifying TCP ports.  I
recommend always requiring the presence of TCP port filed and status
data items in places where they are optional today.

>     - The document doesn't state if there are any ordering requirements
>       on data items. It should be explicit on this, e.g., there are no
>       ordering requirements on the placement of Data Items within
>       Signals.
Fixed.

>     - The required and optional data items that are permitted on a
>       signal isn't always clear.  For example are 0/1/N copies of a
>       particular Data Item required/allowed.  Using something like ABNF
>       would really help formalize and clarify this.

Improved, but errors remain.  For example the Section 8.2 states 'one or
more DLEP data items' , when zero or more is correct.

>     - The document doesn't clearly delineate from informative/narrative
>       text, normative / required processing procedures, and message
>       formats. This by itself is not necessarily a major issue, it just
>       makes it harder to (write,) review and implement the protocol.
>       What is a major issue is that this approach allows for duplicate
>       (and sometimes contradictory) normative procedures and for
>       omissions in procedures (particularly related to exception/error
>       processing).  Specific examples are included above and below.  It
>       would be best to ensure that each required processing behavior is
>       defined just once and in a consistent way.

There is * a lot* of duplicative text in this document. While
consistency is improved, the redundant and scattered definition of
processing makes it very hard to tell if there are omissions or
contradictions.  I strongly recommend that the document remove any
redundant conformance statements.  That is, for any particular
processing or formatting requirement there is only one place that states
the requirement with RFC2119 MUST/SHOULD/MAY language.  Just one example
to illustrate (using idnits line numbering)

392	   DLEP modem implementations MUST announce all metric items that will
393	   be reported during the session, and provide default values for those
394	   metrics, in the Session Initialization Response message
395	   (Section 9.4). 

413	   As mentioned above, DLEP modem implementations MUST announce all
414	   supported metric items during the Session Initialization state.

640	   As mentioned before, the Session Initialization Response message MUST
641	   contain metric data items for all metrics that will be used during
642	   the session. 

1055	   All supported metric data items MUST be included in the Session
1056	   Initialization Response message,

1092	   The Session Initialization Response message MUST contain one of each
1093	   of the following data items, if the data item will be used during the
1094	   lifetime of the session:

Again, this more than just a style point.  It's really hard to tell if
all cases are covered from a review (and implementation) perspective
with the current redundant and distributed approach to processing
conformance.

>     - The security consideration section is inadequate.  This section
>       should address the security of the DLEP protocol, not user
>       traffic.  It should include an analysis of risks/threats/possible
>       exploits and how these are mitigated by the protocol.  rfc6952,
>       and the protocols it references can serve as examples.

I think the DLEP-17 related thread on this pretty much covers my open
concerns.  One point is that authentication of privacy of the discovery
signals/messages also is a concern and should be addressed.  I like the
proposed 802.1AE solution, but have no feel for if the security
directorate/AD will find this acceptable.

> Minor Issues:
>
>     - The data and signal type fields are both 8 bits.  This seems
>       pretty small, particularly the data type field.  Given this is a
>       control protocol, I think a larger (at least data type) field
>       would provide better "future proofing".
fixed.

>     - 2^32 versions are currently allowed (section 8.1).  This seems a
>       bit excessive.  I'd opt for max of 8 bits here myself.
fixed.

>     - It's probably too late, but it probably would be cleaner to have a
>       generic ack signal rather than a per signal type ack. I mention
>       this here as this may come up again when clarifying the
>       transaction model (as mentioned above.)
discussed/updated by doc/closed.

>     - Section 2: Assumptions
>       This section includes informative and normative text so is more
>       than just Assumptions.  Personally, I'd remove all normative text
>       from the section.

Almost fully addressed.  I thing the IPv6 recommendation is a bit
misplaced, and as discussed elsewhere, problematic.

>     - There are no specific rules related to UDP header formation.
This definition is mostly in section 5, but also partially (repeated) in
Section 9.  Pick one, please.

Also v6 is recommended in one place in the document and required in 5.1. 

It's unclear why section 5.1 constrains the source port values.

>     - Sections 8.10->8.17.  Isn't add/drop indicator needed for subnets
>       in destination update signals?
Closed.

>
>     - The IANA Considerations sections must follow​ RFC2360.
Getting closer, but still needs work to fully align with RFC5226. 
Notably absent are Well-Known IANA Policy Definitions and registry
namespaces.

>     - New registries must include initial values, which are defined in
>       the document.  (The document currently has many TBDs that should
>       be replaced.)
Fixed, although message values are defined both in table 1 and in the
body of section 9.
>     - New registries need an allocation policy, e.g.:
>     The registry should be established with registration policies of
>     "Standards Action" (for Standards Track documents) and
>     “Specification Required" (for other documents). The designated
>     expert is any current <fill-in> WG chair.
Still open.

> Nits:
>
>     - The document introduces the terms "signals" and "data items" for
>       what is commonly called "messages" and "TLVs" (or objects) in
>       other protocols.  It's probably too late to change this, but I
>       think the introduction of unique terminology is counter
>       productive.
discussed/updated/closed.

>     - Use of RFC 2119 conformance language is a bit rough, and there are
>       words in all caps that are not defined in RFC2119. Take a look at
>       http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some
>       suggestions.
Still an open issue.  Basically 2119 language should be used to cover
required processing that impacts externally visible behavior.  (It can't
apply to people or informative text.  Also each behavior should be
formally specified only once.  Certainly narrative/informative text
related to the processing can occur in multiple places as makes sense to
describe the solution.

>     - Internal socket operation is mentioned a couple of times.  It
>       really shouldn't be, the spec should define behavior on the wire.
mentioned now only once (line 569) -
>     - The Length fields are missing unit of measure (presumably octets)
fixed.

>     - The Mnemonics are used basically once and don't really add value,
>       suggest dropping them.
closed.
>     - How/when is the "Unknown Signal" Status Code sent?
>
>     - Section 8.7: Extension List should be shown as a variable length
>       field.

fixed.
>     - Section 8.8: Experiment List should be shown as a variable length
>       field.
dropped.

> That's it -- for now -- hopefully I didn't miss anything.  Look forward
> to hearing response to the above (and how I got things hopelessly wrong ;-)

Again good progress.  I do have a few more high level issues that I'll
raise in separate threads.

Lou
> Lou

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 1 Dec 2015 20:30:01 -0500

Lou,

Thanks for the review. I wanted to respond to a couple of your points while
they're fresh on my mind:

On Tue, Dec 1, 2015 at 6:35 PM, Lou Berger <[email-masked]> wrote:

[snip]

> [snip]

The document doesn't mention what an interoperable implementation is
supposed to do with *any* data item. AFAIK, no data item has a "and here's
what you do with it" clause (and if there is one there, please let me know
and I'll delete it). ;-)

What you actually do with the data items is out of scope for this document
- by necessity. If we attempted to document what could (or should) be done
with these data items, the spec is 'deat meat' - we'll be at this for the
next 40 years, since the data (for instance, data rate) *could* be used in
more than one place - the complexity explodes exponentially, the arguing
goes on and on without end. The short answer is - when received, the data
can be a part of your implementation's information base.

Oh, and as to the 2 above data items - they are implemented with
proprietary algorithms. If words to that effect will clear the issue up,
let me know and I'll attempt to add that.

Regards,
Stan

---

From: Lou Berger <[email-masked]>
Date: Tue, 1 Dec 2015 20:51:09 -0500

Stan,

On 12/1/2015 8:30 PM, Stan Ratliff wrote:
> Lou,
>
> Thanks for the review. I wanted to respond to a couple of your points
> while they're fresh on my mind:
>
> On Tue, Dec 1, 2015 at 6:35 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> [snip]
>  
>
> supposed to do with *any* data item. AFAIK, no data item has a "and
> here's what you do with it" clause (and if there is one there, please
> let me know and I'll delete it). ;-)

I think the spec is pretty clear what data items 1-16 mean and are to be
used and to be meaningful in an interoperable scenario.

>
> What you actually do with the data items is out of scope for this
> document - by necessity. If we attempted to document what could (or
> should) be done with these data items, the spec is 'deat meat' - we'll
> be at this for the next 40 years, since the data (for instance, data
> rate) *could* be used in more than one place - the complexity explodes
> exponentially, the arguing goes on and on without end. The short
> answer is - when received, the data can be a part of your
> implementation's information base.
>

for link quality, I think simply saying that the metric can be used (for
example) by a router when selecting between alternate available paths. 
In which case I'd ask why is this limited to 100 rather than the full
range of the field.

for resources, I actually have no guess as to what it means or what you
expect a router to do with this. Without additional information and
assuming your next statement is correct, it's for strictly proprietary
(and non-interoperable) applications, I'd say drop it from the spec.

Lou

> proprietary algorithms. If words to that effect will clear the issue
> up, let me know and I'll attempt to add that.
>
> Regards,
> Stan
>

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 1 Dec 2015 22:36:41 -0500

> example) by a router when selecting between alternate available paths.

That's true for any metric, including "Resources". I respectfully disagree
that we should step into the "... , and here's what you would do with
it..." morass. You said in your response "I think the spec is pretty clear
what data items 1-16 mean and are to be used", but I note again, the spec
doesn't specifically say how (or even whether) they are supposed to be
used. I do not believe we should make an exception for the above two.

Regards,
Stan

---

From: Lou Berger <[email-masked]>
Date: Thu, 3 Dec 2015 17:28:03 -0500

Stan,

On 12/1/2015 10:36 PM, Stan Ratliff wrote:
>
>
> On Tue, Dec 1, 2015 at 8:51 PM, Lou Berger <[email-masked]

any thoughts on the other points?  Some of them a bit more substantive.

>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     > [snip]
>     >
>     >
>     >     >       resources allocated to receiving|transmitting
>     data.".  If
>     >     I were
>     >     >       there's a meaningful, non-proprietary definition for
>     link
>     >     quality
>     >     >       that an implementation is to act on or if the passed
>     value
>     >     is just
> That's true for any metric, including "Resources". I respectfully
> disagree that we should step into the "... , and here's what you would
> do with it..." morass. You said in your response "I think the spec is
> pretty clear what data items 1-16 mean and are to be used", but I note
> again, the spec doesn't specifically say how (or even whether) they
> are supposed to be used. I do not believe we should make an exception
> for the above two.

If I was to implement the router side, I'd know what to do with the
other items, but not resource.  I defer to the WG to come to consensus
on this question (and if the full value range is permissible.)

I look forward to hearing back on the other open topics.

Lou

---

From: Henning Rogge <[email-masked]>
Date: Thu, 3 Dec 2015 23:36:58 +0100

> on this question (and if the full value range is permissible.)

My interpretation was always something like "battery level"... might
make sense if the router is just a virtual software instance running
on the radio hardware but using the standardized DLEP interface to get
its data.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 3 Dec 2015 17:41:08 -0500

Lou,

With regard to the other points you raise, I'm thinking we (Rick and
myself) need to address them with an update. There are a few I'm frankly
struggling with, and I'd like to reserve the option of coming back & saying
"I don't get it", but...

As long as you're asking, I do have one question - when discussing the
transaction model, you say (in part):
" More significantly, it's unclear how new messages should be handled."

Since we're talking about new messages, and I have no idea what those
messages would involve, it's somewhat hard to fully pin-down how they
should be handled. If the new messages are destination-oriented, they
should fall into the "1 transaction in-flight per destination" rule. If the
new messages are peer-oriented, then they would fall into the "1
transaction in-flight per peer" rule... but in the case where a new message
introduces some sort of new context that I can't currently see? I'm lost
there.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Fri, 4 Dec 2015 05:52:44 +0000

Lou, et al.

I'm afraid I'm on vacation until the 14th, so I'm resisting the urge to
reply to some of the questions rather than leaving Stan out to dry.

As Stan said, I think we will have to address your, and the other (thank
you all) comments with an update.

We will attempt to get something out ASAP, vacations permitting.

Cheers,

Rick

On 03/12/15 22:41, Stan Ratliff wrote:
> myself) need to address them with an update. There are a few I'm
> frankly struggling with, and I'd like to reserve the option of coming
> back & saying "I don't get it", but... 
>
> should fall into the "1 transaction in-flight per destination" rule.
> If the new messages are peer-oriented, then they would fall into the
> "1 transaction in-flight per peer" rule... but in the case where a new
> message introduces some sort of new context that I can't currently
> see? I'm lost there.
>
> Regards,
> Stan
>
>
>
> On Thu, Dec 3, 2015 at 5:28 PM, Lou Berger <[email-masked]
>     >     > On Tue, Dec 1, 2015 at 6:35 PM, Lou Berger
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >
>     >     > [snip]
>     >     >
>     >     >
>     >     >     >     - Sections 8.19 and 8.20 define "Resources"
>     related Data
>     >     >     Items.  The
>     >     >     >       implementing this protocol, I'd have no idea
>     how to
>     >     produce,
>     >     >     >       informative and normative (RFC 2119) text
>     related to
>     >     these
>     >     >     >       formats.
>     >     >
>     >     >     >     - Sections 8.21 and 8.22 (Relative Link Quality)
>     have
>     >     a similar
>     >     >     >       problem of being under described, in
>     particular it's
>     >     >     unclear if
>     >     >     >       passed for as monitoring information.  Either
>     way, this
>     >     >     needs to
>     >     >     >       be clarified.
>     >     I think the spec is pretty clear what data items 1-16 mean
>     and are
>     >     to be
>     >     > should) be done with these data items, the spec is 'deat
>     meat' -
>     >     we'll

---

From: Lou Berger <[email-masked]>
Date: Fri, 4 Dec 2015 10:15:09 -0500

Stan,

On 12/3/2015 5:41 PM, Stan Ratliff wrote:
> Lou,Â 
> myself) need to address them with an update.

I think the technical issues should be discussed on list before making
changes.Â  Editorial issues can be addressed as you/the editors/the
chairs see fit.

> There are a few I'm frankly struggling with, and I'd like to reserve
> the option of coming back & saying "I don't get it", but...Â 
>
Please do.

> transaction model, you say (in part):Â 
> "Â MoreÂ significantly, it's unclear how new messages should be handled."
>
> should be handled.
Part of this could be simply saying that if an unknown message is
received it is silently discarded, and may be reported via management
interfaces, e.g., counter increment or logging.Â  Also that any new
message types must identify their transaction class (destination or
session), alternately this can be implicit based on presence of the MAC
address data item...

> If the new messages are destination-oriented, they should fall into
> the "1 transaction in-flight per destination" rule. If the new
> messages are peer-oriented, then they would fall into the "1
> transaction in-flight per peer" rule... but in the case where a new

I think the transaction model has come a long way (from no definition),
but it doesn't match my understanding of what was previously discussed
(single transaction. period.) and the model should be flushed out more
fully as well as discussed by the WG  In particular, I think it would be
good to hear from those who have implementations and their
experience/perspective.

Lou

>     >Â  Â  Â Stan,
>     >Â  Â  Â On 12/1/2015 8:30 PM, Stan Ratliff wrote:
>     >Â  Â  Â > Lou,
>     >Â  Â  Â >
>     >Â  Â  Â > Thanks for the review. I wanted to respond to a couple
>     of your
>     >Â  Â  Â points
>     >Â  Â  Â > while they're fresh on my mind:
>     >
>
>     any thoughts on the other points?Â  Some of them a bit more
>     substantive.
>
>
>     >Â  Â  Â >
>     >Â  Â  Â > On Tue, Dec 1, 2015 at 6:35 PM, Lou Berger
>     >Â  Â  Â <mailto:[email-masked] <mailto:[email-masked]>>
>     >Â  Â  Â > <mailto:[email-masked] <mailto:[email-masked]>
>     >Â  Â  Â >
>     >Â  Â  Â > [snip]
>     >Â  Â  Â >
>     >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â - Sections 8.19 and 8.20 define
>     "Resources" related Data
>     >Â  Â  Â >Â  Â  Â Items.Â  The
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â definition related to these
>     basically says a
>     >Â  Â  Â resources is "An
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â 8-bit integer percentage, 0-100,
>     representing the
>     >Â  Â  Â amount of
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â resources allocated to
>     receiving|transmitting
>     >Â  Â  Â data.".Â  If
>     >Â  Â  Â >Â  Â  Â I were
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â implementing this protocol, I'd have
>     no idea how to
>     >Â  Â  Â produce,
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â update or use this information.Â  I
>     think there is
>     >Â  Â  Â some missing
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â informative and normative (RFC 2119)
>     text related to
>     >Â  Â  Â these
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â formats.
>     >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â Unless I missed it, no change.
>     >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â The basic point is that the document should
>     state what are
>     >Â  Â  Â >Â  Â  Â interoperable
>     >Â  Â  Â >Â  Â  Â implementations supposed to do with this parameter.
>     >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â - Sections 8.21 and 8.22 (Relative Link
>     Quality) have
>     >Â  Â  Â a similar
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â problem of being under described, in
>     particular it's
>     >Â  Â  Â >Â  Â  Â unclear if
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â there's a meaningful,
>     non-proprietary definition for
>     >Â  Â  Â link
>     >Â  Â  Â >Â  Â  Â quality
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â that an implementation is to act on
>     or if the passed
>     >Â  Â  Â value
>     >Â  Â  Â >Â  Â  Â is just
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â passed for as monitoring
>     information.Â  Either way, this
>     >Â  Â  Â >Â  Â  Â needs to
>     >Â  Â  Â >Â  Â  Â >Â  Â  Â  Â be clarified.
>     >Â  Â  Â >Â  Â  Â Unless I missed it, no change.
>     >Â  Â  Â >
>     >Â  Â  Â >Â  Â  Â The basic point is that the document should
>     state what are
>     >Â  Â  Â >Â  Â  Â interoperable
>     >Â  Â  Â >Â  Â  Â implementations supposed to do with this parameter.
>     >Â  Â  Â >
>     >Â  Â  Â > [snip]
>     >Â  Â  Â >
>     >Â  Â  Â > The document doesn't mention what an interoperable
>     implementation is
>     >Â  Â  Â > supposed to do with *any* data item. AFAIK, no data
>     item has a "and
>     >Â  Â  Â > here's what you do with it" clause (and if there is one
>     there,
>     >Â  Â  Â please
>     >Â  Â  Â > let me know and I'll delete it). ;-)
>     >
>     >Â  Â  Â I think the spec is pretty clear what data items 1-16
>     mean and are
>     >Â  Â  Â to be
>     >Â  Â  Â used and to be meaningful in an interoperable scenario.
>     >
>     >Â  Â  Â >
>     >Â  Â  Â > What you actually do with the data items is out of
>     scope for this
>     >Â  Â  Â > document - by necessity. If we attempted to document
>     what could (or
>     >Â  Â  Â > should) be done with these data items, the spec is
>     'deat meat' -
>     >Â  Â  Â we'll
>     >Â  Â  Â > be at this for the next 40 years, since the data (for
>     instance, data
>     >Â  Â  Â > rate) *could* be used in more than one place - the
>     complexity
>     >Â  Â  Â explodes
>     >Â  Â  Â > exponentially, the arguing goes on and on without end.
>     The short
>     >Â  Â  Â > answer is - when received, the data can be a part of your
>     >Â  Â  Â > implementation's information base.
>     >Â  Â  Â >
>     >
>     >Â  Â  Â for link quality, I think simply saying that the metric
>     can be
>     >Â  Â  Â used (for
>     >Â  Â  Â example) by a router when selecting between alternate
>     available paths.
>     >
>     >
>     other items, but not resource.Â  I defer to the WG to come to
>     consensus
>     >Â  Â  Â In which case I'd ask why is this limited to 100 rather
>     than the full
>     >Â  Â  Â range of the field.
>     >
>     >Â  Â  Â for resources, I actually have no guess as to what it
>     means or
>     >Â  Â  Â what you
>     >Â  Â  Â expect a router to do with this. Without additional
>     information and
>     >Â  Â  Â assuming your next statement is correct, it's for
>     strictly proprietary
>     >Â  Â  Â (and non-interoperable) applications, I'd say drop it
>     from the spec.
>     >
>     >Â  Â  Â Lou
>     >
>     >Â  Â  Â > Oh, and as to the 2 above data items - they are
>     implemented with
>     >Â  Â  Â > proprietary algorithms. If words to that effect will
>     clear the issue
>     >Â  Â  Â > up, let me know and I'll attempt to add that.
>     >Â  Â  Â >
>     >Â  Â  Â > Regards,
>     >Â  Â  Â > Stan
>     >Â  Â  Â >
>     >
>     >
>     >
>
>
>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 4 Dec 2015 10:38:46 -0500

Lou,

> changes.Â  Editorial issues can be addressed as you/the editors/the

If there are specific technical issues you want discussed, then please let
me know. From an admittedly quick re-read of your last review, it seemed
that the biggest issue was that of IPv6-mandated discovery. We agree that
this should be both IPv4 and IPv6 based, and will change the doc to reflect
that.

> session), alternately this can be implicit based on presence of the MAC

OK. I can go for some text along the lines of
"Extensions to this draft that contain new messages MUST clearly state
whether a message is a destination message, or a peer message. Those new
messages MUST NOT violate the existing transaction model."   ??

> good to hear from those who have implementations and their

The documented transaction *is* the viewpoint of at least one
implementer... ;-) It's what I'd done at my previous company. Can you give
me an example of the additional flushing out that needs to be done? I'm
looking for a place to start.

Regards,
Stan

[snip]

---

From: Lou Berger <[email-masked]>
Date: Fri, 4 Dec 2015 18:10:22 -0500

On 12/4/2015 10:38 AM, Stan Ratliff wrote:
> Lou, 
>
>
> On Fri, Dec 4, 2015 at 10:15 AM, Lou Berger <[email-masked]
> If there are specific technical issues you want discussed, then please
> let me know. From an admittedly quick re-read of your last review, it
> seemed that the biggest issue was that of IPv6-mandated discovery. We
> agree that this should be both IPv4 and IPv6 based, and will change
> the doc to reflect that. 
>

from my prior message, the raised open technical issues that I'd expect
to be resolved on list are:
- agreeing on the transaction model (see below)
- documenting handling of TCP close
- handling failures in destination processing (while session processing
continues)
- replacement of 'heuristics' with defined mechanisms
- eliminating duplicate functionality
    1) always require status where currently optional
    2) always require TCP port where currently optional
- Security of UDP messages
- eliminating required range for source ports

The main editorial points, which I think is fine for the
authors/editors/etc, try to address on their own:
- Elimination of duplicate conformance requirements
- General cleanup of conformance language
- Rewrite IANA section to fully align with RFC5226
- (hopefully) addition of ABNF
- Addition clarification / definition of states and transitions (maybe
even state diagrams, again see
https://tools.ietf.org/html/rfc4204#section-11 for a very similar protocol.)
- Fixing the scaling considerations section

> whether a message is a destination message, or a peer message. Those
> new messages MUST NOT violate the existing transaction model."   ??
>
Assuming there are two transaction classes, I'd personally address this
by putting a bit in the message to indicate the message transaction
class.  This would ensure there is no ambiguity now and in perpetuity. 

> implementer... ;-)
Fair enough.  I made my comment as the current version didn't match
(perhaps just my memory) of what I had been told was implemented.

> It's what I'd done at my previous company. Can you give me an example
> of the additional flushing out that needs to be done? I'm looking for
> a place to start. 
>
- Explicit identification of message transaction class (the bit
mentioned above)
- Handling of destination transaction failures when there are no session
errors
    - e.g., no response, or destination down or updated during
destination specific transaction
- Handling of TCP closes

Lou