Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Jun 2015 14:40:21 -0400

% Document: draft-ietf-manet-dlep-14
% Reviewer: Lou Berger
% Review Date: June 8 (later than requested due to scope of comments -- sorry)
% WG LC End Date: unknown
% Intended Status: Standards track
% 
% Summary:
%
%   While I think the document is pretty decent for the scope of the
%   work, I do have concerns about this document and recommend that the
%   WG Chairs/Routing ADs discuss these issues further with the authors.
%   I'm also available as/if needed to discuss.

I broadly agree with Lou's review.  A point-by-point commentary
follows in-line.

I think the document needs both clarifications (e.g. more text
that is more crisply and clearly written) and also some modest
protocol changes.

% Comments:
%
%   I think the document shows significant good work and looks to be a
%   useful protocol, although I'm not overly familiar in this space.
%   That said, I have a number of serious concerns about the document,
%   and its contents from a few of perspectives.  These include basic
%   protocol issues, underspecified details  (which could lead to
%   interoperability issues), and specification/editorial issues. I
%   think the document / protocol can be modified to address the issues
%   I raise below.  Of course, it is up to the WG, chairs, and ADs to
%   decide which comments to address and which to  ignore. 
%   I don't expect that all comments will result in changes.

As context, I am a consultant and I work regularly with a
well-known radio vendor that designs/sells IP-capable radios.

% 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.

Agreed.  This field is clearly too small.  I propose that it be
changed to be a 16-bit field, which should be ample.  

%   - 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).

Agreed.  This issue has been a problem in a few other IETF
protocols. It is MUCH preferable from a protocol evolution
perspective to have the version placed in a location where
potential future protocol format changes are both possible 
and practical.

I also agree the field is WAY too large.  The field should not
be larger than 8-bits.  In fact, I would be surprised if any
IETF protocol needed  more than 4-bits worth of version.

%   - 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.

Agreed.  Undefined states are problematic in any protocol.
They are likely to lead to interoperability issues that
can be avoided either by more clear definition xor by
elimination of these states.

%   - TCP session management is not defined, nor is the relationship
%     with TCP and DLEP sessions fully defined.  For example:

I agree.  I view this as a specification clarity issue.

%     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).

IMHO, DLEP ought not be defining/describing a TCP session close 
in a way that is inconsistent with normal TCP behavior.

%     o What happens when a DLEP session is terminated, can the TCP
%       session be reused or must it be closed too?

IMHO, the DLEP specification should say that a NORMAL TCP close
(i.e. not just sending an abrupt TCP RESET) occurs when a DLEP 
session terminates.

%   - 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.  

Agreed.

%   - 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.

I agree with the question.

%   - 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?

I agree with the question.  I believe that a more crisp
and clear text description is the minimum needed on this.

%   - 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.

Some discussion seems needed.  If the authors believe there
really aren't any, perhaps they could add text with a description
of why they aren't any.

%   - 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.

I agree.  We need interoperability.  A clear and complete
specification is the best way to achieve interoperability.

%   - 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 ?

I don't see an obvious reason for the two kinds of data items
to have different syntax (numeric values vs UTF-8 strings).
As neas as I can tell, parsing would be simpler if a single form 
(ideally numeric) were used.

%   - 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.

I think I understand what this chunk of text means, and I think
that I understand how different radios could calculate this in
different ways (e.g. a pure software radio might be different
than a silicon-based radio), but I also think that additional
clarifying text would help with interoperability.  Maybe we could
add examples relating to memory or CPU or whatever.

It seems to me that "if a device cannot calculate" these values,
then that device MUST NOT (rather than SHOULD NOT) send this data
item.  Sending a data item containing an erroneous or misleading
value does not seem helpful to either end of the DLEP session.

%   - 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.

I think I understand what this chunk of text means, and I totally
get that different radio types could calculate this in very
different ways, but I also think that additional clarifying text
(possibly adding examples) would help with interoperability.

As above, I think that this data item "MUST NOT" be sent
(rather than "SHOULD NOT") if the device is unable to calculate
any link quality metric, because sending erroneous or
misleading data does not seem helpful to either end of the
DLEP session.

%   - 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.   

I understand the value of having some flexibility, but I also
agree that more description than exists now is needed for
interoperability reasons.

%   - 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.

Agree.  Avoidable complexity or low ROI complexity seems
undesirable.

%   - 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.

This needs to be specified either as "no ordering requirements"
xor whatever the requirements are.  My preference is to say
explicitly "Data Items can be placed in any order within
Signals."  

%   - 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.

More clarity would help interoperability.

%   - 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.

Agree.

%   - 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.

TCP session hijacking is known to have been practical on the
deployed Internet at least since 1995.  CERT Advisories
CA-1995-01, CA-1996-21, and CA-2001-09 are historical examples.
There is also a practical DOS risk from an adversary sending
a forged TCP Reset message.

I suspect most of us envision that the router and the radio
would be on a single VLAN or Ethernet collision domain, and
that generally that wire might have some *assumed* trust
associated with it.  However, large Ethernet bridged LANs
are now commonplace, including multi-site bridged LANs
(e.g. to enable VM migration without IP readdressing). 

So *some* kind of session authentication mechanism ought to
be specified, so that we have some chance of interoperating
in an authenticated way.

My suggestion is that TCP-AO (RFC-5925) be specified as a
mandatory to implement authentication method, but there are other
IETF standards-track alternatives (e.g. IPsec AH or IPsec ESP).
I imagine that most modern IP routers support TCP-AO already.
Ideally we would like something that protects against forged TCP
Reset messages, which means TLS is not a great choice.

% 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".

For me, this is a MAJOR issue.  There are radios that will
need to define radio-specific data items.  In future, there
likely will be a growing number of such data items, even if
some of the experimental data items later are standardised.

So each of these fields needs to be larger than 8-bits.  I think
16-bits would be big enough.  Trying to push all experimental
extensions (or radio-unique extensions) into a single
"Experimental Definition" followed by text strings makes parsing
needlessly complex and doesn't really fit the engineering need to
have radio-specific extensions to DLEP.  Instead, we ought to
specify that IANA allocates new Data Item type codes (numeric)
for each experimental status data item.

Also, the IANA Considerations should specify that experimental
status Data Item values are allocated on a "First Come, First
Serve" basis and should say that "RFC publication of the data
item definition is encouraged, but is NOT required for
experimental data item allocations."

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

If an IETF protocol needs more than 4-bits for version,
then IMHO something is very wrong.  

I can live with an 8-bit field for alignment reasons, but we
surely ought not need a 16-bit field for this.

On a related note, I see no reason for having a minor version.
NFS is the only IETF protocol that I can think of with both major
and minor versions.  NFS WG went to some effort to describe the
difference between what would change the Major Version versus the
Minor Version, which this does NOT do.  Either (1) drop the Minor
Version entirely or (2) document (a) the compelling reason to
keep the Minor Version and (b) exactly when a change would alter
the Minor Version and (c) exactly when a change would alter the
Major Version.

%   - 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.)

I could go either way on this, provided the conclusion were 
very clear.

%   - 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.

I very much doubt that J. Random implementer who is handed
the DLEP document and told to code it up will expect guidance
or normative language to be in a section marked "Assumptions".

Perhaps keep the non-normative text inside "Assumptions",
but place the guidance ("normative language") in a new
section (possibly somewhere in Section 3) that is clearly 
normative guidance.  

%   - There are no specific rules related to UDP header formation.

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

Good question.

%   - The IANA Considerations sections must follow⃫刀䘀䌀㈀㌀㘀　⸀ഀഀ匀攀攀 愀戀漀瘀攀 昀漀爀 漀琀栀攀爀 搀椀猀挀甀猀猀椀漀渀 昀爀漀洀 洀攀 愀戀漀甀琀 䤀䄀一䄀 䌀漀渀猀椀搀攀爀愀琀椀漀渀猀⸀ഀഀ─  ⴀ 一攀眀 爀攀最椀猀琀爀椀攀猀 洀甀猀琀 椀渀挀氀甀搀攀 椀渀椀琀椀愀氀 瘀愀氀甀攀猀Ⰰ 眀栀椀挀栀 愀爀攀 搀攀昀椀渀攀搀 椀渀ഀ─    琀栀攀 搀漀挀甀洀攀渀琀⸀  ⠀吀栀攀 搀漀挀甀洀攀渀琀 挀甀爀爀攀渀琀氀礀 栀愀猀 洀愀渀礀 吀䈀䐀猀 琀栀愀琀 猀栀漀甀氀搀ഀ─    戀攀 爀攀瀀氀愀挀攀搀⸀⤀ഀഀ─   ⴀ 一攀眀 爀攀最椀猀琀爀椀攀猀 渀攀攀搀 愀渀 愀氀氀漀挀愀琀椀漀渀 瀀漀氀椀挀礀Ⰰ 攀⸀最⸀㨀ഀ─   吀栀攀 爀攀最椀猀琀爀礀 猀栀漀甀氀搀 戀攀 攀猀琀愀戀氀椀猀栀攀搀 眀椀琀栀 爀攀最椀猀琀爀愀琀椀漀渀 瀀漀氀椀挀椀攀猀 漀昀ഀ─   ∀匀琀愀渀搀愀爀搀猀 䄀挀琀椀漀渀∀ ⠀昀漀爀 匀琀愀渀搀愀爀搀猀 吀爀愀挀欀 搀漀挀甀洀攀渀琀猀⤀ 愀渀搀ഀ─   ﰀSpecification Required" (for other documents). The designated
%   expert is any current <fill-in> WG chair.

I disagree about "Specification Required" for experimental status
Data Items that are defined.  Those should be allocated by IANA
on a "First Come, First Served" basis with "Specification Optional".

% 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.

Agree.  This makes the learning curve for DLEP steeper than it
needs to be.

%   - Use of RFC 2119 conformance language is a bit rough, and there are
%     words in all caps that are not defined in RFC2119. 

I agree this is an issue.  I doubt the document will get past
the IESG until this is fixed.  Fixing it now ought to speed
the rest of the IETF process.

%   - Internal socket operation is mentioned a couple of times.  It
%     really shouldn't be, the spec should define behavior on the wire.

Agree.

%   - The Length fields are missing unit of measure (presumably octets)

Agree.  We need to specify units of measure to ensure
interoperability.

%   - The Mnemonics are used basically once and don't really add value,
%     suggest dropping them.

No objection.

%   - How/when is the "Unknown Signal" Status Code sent?

Clarifying text is needed for this.

%   - Section 8.7: Extension List should be shown as a variable length
%     field.
%
%   - Section 8.8: Experiment List should be shown as a variable length
%     field.

I think we ought to get away from having separate Extension
List and Experiment List.  In reality, both are extensions,
some having experimental status.  Right ?  Please lets simplify
the protocol in this area and make interoperability easier to achieve.

Yours,

Ran Atkinson

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 19 Jun 2015 14:23:09 +0000

Hi,

Here are a few comments on topics that resonated with me, piggybacked on
excerpts of Ran's reply because it was so similar to my thoughts.  For
context, I am the main developer working on our DLEP implementation.  I'm
a relative newcomer to DLEP (this year), so I have fresh eyes :)

>potential future protocol format changes are both possible

Good point.  It should be a fixed field in header of the Peer Discovery
and Peer Offer signals, and since discovery is optional, it should also be
in the Peer Initialization and Peer Initialization Ack signals.  Perhaps
it would be simpler to just put it in the header for all signals.

>IETF protocol needed  more than 4-bits worth of version.

I have seen 16 bit version numbers work in other (non-IETF) protocols,
with one byte each for the major and minor versions.  As Ran points out
later, this would require careful definition of what it means when each
one changes, and that may not be worth the effort.  I don't feel strongly
about this.  The interaction between version number changes and the
extension mechanism(s) needs thought too.

>elimination of these states.

If it's of any use, we ended up defining our own states for our
implementation:

- Connected: the TCP connection is established between the peers, but the
Init handshake hasn't completed.
- In Session: the Peer Init/Ack exchange is complete, and other signals
can now be sent.
- Terminating: a Termination signal has been sent to the peer, and we are
waiting for the Ack.
We didn't use the "discovery" state because our states are attached to
peers, and during discovery there is no peer.

>specification is the best way to achieve interoperability.

Agree.  We have implemented 'heuristics', and while I think they should
work with other implementations, I'm not sure.  I would be more
comfortable if the behavior was more completely specified.

>(ideally numeric) were used.

I've been puzzled about the two very similar extension mechanisms, but I
figured it had all been hashed out before I started with DLEP.  Now that
others are raising the issue though, I'll say that I do think it would be
good to combine them.  I'm concerned about how to mesh the two different
mechanisms in the implementation.  A possible way to combine them would be
to have a 16 bit extension number, with half of the space reserved for
standardized extensions and half for experimental/non-standard ones.
Perhaps IANA could even assign the experimental ones on a
first-come-first-serve, no spec required basis to help with
interoperability.

>interoperability reasons.

Agree.  The credit scheme will be important to us.

>Ran Atkinson

David Wiggins
MIT Lincoln Laboratory

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Fri, 19 Jun 2015 16:09:28 +0000

OK, since the debate seems to be brewing over "Extensions" and "Experimental Definitions", I figured I'd jump in and try to explain. 

> >I don't see an obvious reason for the two kinds of data items to have
> >different syntax (numeric values vs UTF-8 strings).
> others are raising the issue though, I'll say that I do think it would be good to
> combine them.  I'm concerned about how to mesh the two different
> mechanisms in the implementation.  A possible way to combine them would
> be to have a 16 bit extension number, with half of the space reserved for
> Perhaps IANA could even assign the experimental ones on a first-come-first-
> serve, no spec required basis to help with interoperability.
> 

So, let's start with a scenario - assume that DLEP is now RFC-blah-de-blah, and I have an interoperable version deployed. The sun is rising in the East, the crops are bountiful, and I've *finally* lost that pesky 30lbs (OK, more like 40) that my doctor keeps needling me about. And then... I get this great idea, having to do with DLEP. With a small handful of data items, and a correspondingly small number of signals, I can put an "It-will-even-make-coffee-for-you-in-the-morning" feature in my modem. But, DLEP is this fixed, interoperable protocol. So what to do, what to do?

With the -14 draft, I can implement this, *initially*, as an "Experiment". I conjure up the necessary signals ("DLEP_COFFEEMAKER_START", "DLEP_COFFEEMAKER_STOP"), and also the requisite data items ("DLEP_COLUMBIAN")... actually, I'd probably add "DLEP_SUMATRAN", since this is a "high-end" modem, but that's another story...
I also map out how these signals/data items look (e.g., is the DLEP_COLUMBIAN data item 8 bits, 16 bits, or just 1?), and then I start looking for a router vendor to "play nice with me", and support my coffee maker experiment. Assuming I find such a router vendor, we implement the "Coffee Maker Experiment" - and again, since this is *my* scenario, we'll assume that's its wildly successful. All of my beta test sites are "Slurping coffee on the move", and enjoying it. In fact, it's so wildly popular that other modem manufacturers are now discussing bolting coffee makers onto their modems...

So, at this point, it's time for me and my router-vendor partner to approach the MANET WG with a draft describing the Coffee-Maker "Experiment" as a DLEP "Extension". And true to form, the WG debates the weighty issues (e.g., Should there be a DLEP_ARABICA data item? NO! YES! Wait! We should allow it to MAKE TEA! Yes, that's the ticket! It MUST [proper homage to RFC 2119] contain a DLEP_EARL_GREY data item!), ad-nauseum, over a period of time that you thought would take a couple of IETF meetings, but actually spans about 5 years (in other words, you *thought* it was going to be a project, but it turned into a career path)...

Finally, clearing Working Group Last Call (and *then* getting a crap-ton of really useful comments, because apparently, no one reads these things unless/until there's supposedly no chance to change them), you get the official, approved, "DLEP Coffee Maker Extension" registered with IANA... I and my router-vendor partner (actually, my grandchild and my router-vendor partner's grandchild, since it's taken so long) can then swap over our code to stop using the "Experiment", and use the official "Extension" data items and signals.

But my point here is, that all the while, my customers have been merrily "slupring coffee on the move, and enjoying it" - utilizing the "Experimental" TLVs gives me (us, actually) the ability to actually be *responsive* to our customers, testing out (and even deploying in limited fashion) changes to the protocol. If/when those "experiments" prove successful, the mechanism even gives implementers the ability to shift the code from "Experiment" to "Extension", providing backward-level compatibility for the move (nothing stops me from supporting the exact same functionality in "Experimental" mode that I'm supporting with a now-documented "Extension"). 

...and that was the motivation behind having both "Experimental" TLVs, and a documented "Extension" mechanism... 

Regards,
Stan

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Jun 2015 18:17:51 +0200

> ...and that was the motivation behind having both "Experimental" TLVs, and a documented "Extension" mechanism...

The "text identifier" of the Experiments make it also much easier to
have multiple experiments in house and even do small tests with other
software without worrying about which "experimental number" to take
from the Extension so that you don't have collisions.

Henning

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 19 Jun 2015 17:16:41 +0000

Hi Stan,

Thanks for the clarifications.  And the humor is appreciated.

If I go through your story, and everywhere it mentions "experiment" I
replace it with "experimental extension" using this notion:

    a 16 bit extension number, with half of the space reserved for
    standardized extensions and half for experimental/non-standard ones.
    Perhaps IANA could even assign the experimental ones on a
first-come-first-
    serve, no spec required basis to help with interoperability.

...then I think the story still works.  If I'm wrong, I've missed
something.  The advantage is that now you just have one extension
mechanism instead of two.  No more questions about how the two mechanisms
relate to/interact with one another (and no new words needed to describe
such interactions), since there's only one now.  No need to implement two
sets of extension-handling code.  Seems like a win.

David

On 6/19/15, 12:09 PM, "Ratliff, Stanley" <[email-masked]> wrote:

>OK, since the debate seems to be brewing over "Extensions" and
>"Experimental Definitions", I figured I'd jump in and try to explain.
>
>> >
>>first-come-first-
>So, let's start with a scenario - assume that DLEP is now
>RFC-blah-de-blah, and I have an interoperable version deployed. The sun
>is rising in the East, the crops are bountiful, and I've *finally* lost
>that pesky 30lbs (OK, more like 40) that my doctor keeps needling me
>about. And then... I get this great idea, having to do with DLEP. With a
>small handful of data items, and a correspondingly small number of
>signals, I can put an "It-will-even-make-coffee-for-you-in-the-morning"
>feature in my modem. But, DLEP is this fixed, interoperable protocol. So
>what to do, what to do?
>
>With the -14 draft, I can implement this, *initially*, as an
>"Experiment". I conjure up the necessary signals
>("DLEP_COFFEEMAKER_START", "DLEP_COFFEEMAKER_STOP"), and also the
>requisite data items ("DLEP_COLUMBIAN")... actually, I'd probably add
>"DLEP_SUMATRAN", since this is a "high-end" modem, but that's another
>story...
>I also map out how these signals/data items look (e.g., is the
>DLEP_COLUMBIAN data item 8 bits, 16 bits, or just 1?), and then I start
>looking for a router vendor to "play nice with me", and support my coffee
>maker experiment. Assuming I find such a router vendor, we implement the
>"Coffee Maker Experiment" - and again, since this is *my* scenario, we'll
>assume that's its wildly successful. All of my beta test sites are
>"Slurping coffee on the move", and enjoying it. In fact, it's so wildly
>popular that other modem manufacturers are now discussing bolting coffee
>makers onto their modems...
>
>So, at this point, it's time for me and my router-vendor partner to
>approach the MANET WG with a draft describing the Coffee-Maker
>"Experiment" as a DLEP "Extension". And true to form, the WG debates the
>weighty issues (e.g., Should there be a DLEP_ARABICA data item? NO! YES!
>Wait! We should allow it to MAKE TEA! Yes, that's the ticket! It MUST
>[proper homage to RFC 2119] contain a DLEP_EARL_GREY data item!),
>ad-nauseum, over a period of time that you thought would take a couple of
>IETF meetings, but actually spans about 5 years (in other words, you
>*thought* it was going to be a project, but it turned into a career
>path)...
>
>Finally, clearing Working Group Last Call (and *then* getting a crap-ton
>of really useful comments, because apparently, no one reads these things
>unless/until there's supposedly no chance to change them), you get the
>official, approved, "DLEP Coffee Maker Extension" registered with IANA...
>I and my router-vendor partner (actually, my grandchild and my
>router-vendor partner's grandchild, since it's taken so long) can then
>swap over our code to stop using the "Experiment", and use the official
>"Extension" data items and signals.
>
>But my point here is, that all the while, my customers have been merrily
>"slupring coffee on the move, and enjoying it" - utilizing the
>"Experimental" TLVs gives me (us, actually) the ability to actually be
>*responsive* to our customers, testing out (and even deploying in limited
>fashion) changes to the protocol. If/when those "experiments" prove
>successful, the mechanism even gives implementers the ability to shift
>the code from "Experiment" to "Extension", providing backward-level
>compatibility for the move (nothing stops me from supporting the exact
>same functionality in "Experimental" mode that I'm supporting with a
>now-documented "Extension").
>
>...and that was the motivation behind having both "Experimental" TLVs,
>and a documented "Extension" mechanism...
>
>Regards,
>Stan
>
>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Fri, 19 Jun 2015 17:50:45 +0000

David,

>     serve, no spec required basis to help with interoperability.

As it has been explained to me, that notion collides with IANA/IESG in at least a couple of not-so-nice ways: 
1. Creating a "standards-track protocol" with 32,767 experiments, and another 32,767 extensions, isn't much of a standard - everything's pretty much an experiment or an extension. 
2. I don't believe IANA operates that way. They need a WG-approved document in order to start the assignment process. 

So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" (the experiments), and the more formal Extensions mechanism, which by necessity, starts with an IETF draft. 

Regards,
Stan

[snip]

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 19 Jun 2015 19:51:47 +0000

On 6/19/15, 1:50 PM, "Ratliff, Stanley" <[email-masked]> wrote:

>1. Creating a "standards-track protocol" with 32,767 experiments, and
>another 32,767 extensions, isn't much of a standard - everything's pretty
>much an experiment or an extension.

The core protocol as defined in the draft/RFC isn't an extension or an
experiment, and that's what is being standardized, at least initially.
I'm not sure why IANA/IESG would have an issue with the number of
extensions or experiments allowed.

> 
>2. I don't believe IANA operates that way. They need a WG-approved
>document in order to start the assignment process.

OK.  I was under the impression that there could be different rules for
experimental extensions in other cases, and they could do a lightweight
assignment, but I am no authority here.  Maybe someone who knows can chime
in.

David

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 19 Jun 2015 22:12:28 +0100

I'm not claiming to be an authority, but I've had some experience. This is my observation of how I've seen things work, rather than anything official. As such if, for example, someone comes along and points out that I've misstated something, with proper references, believe them not me.

And I also realise this is a post which many will see as teaching egg sucking. Those who do, please do improve on it.

To make things more complicated, we have at least two overlapping concepts.

First, when we allocate a number space, we typically allocate some numbers for private or experimental use. (Those two aren't exactly the same, but close enough for these purposes.) Essentially I shouldn't let things using those numbers escape onto the wider Internet, they should be confined to my network. And on my network I can do what I like. You can use the same number in that space for something completely different in your network. Those numbers aren't allocated. Typically the rest are allocated by IANA (usually subject to some sort of review process, which makes it not quite first come first served).

Then, separately, I can create something that builds on (extends) a standard protocol. Obviously I can do that privately, and no one else will care, because no one else will know. But if I want to do it more broadly I will publish an Internet Draft. While in that state, now lots of people can try it out on their private networks, and we can even try joining our networks together (especially possible in a MANET). But again we ought not to pollute the public Internet.

We may then progress to an RFC. Which might be experimental or a Proposed Standard (it could also be informational, but I won't go there). Obviously in the standard case we should be able to use it publicly. I'm not sure what the exact rules are in the experimental case, but I would assume we should at the least be very wary of letting things out or not do so at all depending on the next point.

Which is that any extension (private, ID, experimental or standard) might be backwardly compatible or not. A non-backwardly compatible standard will have had to jump through lots of hard hoops. I'm not sure how hard a non-backwardly compatible experimental RFC is to get accepted as I haven't had to try that. But it's a good idea to design your protocol to make compatible extensions possible (which means considering things like what to do with an unknown object).

Now crossing the two (allocations and extensions) typically an extension needs new allocations. (Not always, but let's assume it does.) Obviously a new standard is easy to get an allocation for (unless space is low). Whether a new experimental RFC can get an allocation depends on the rules set up when the appropriate registry is defined. That should be in the RFC that defines the register. There's an RFC (sorry, number not to hand) that lists the options here. But it's perfectly possible to set up a registry so that experimental protocols can claim from the IANA allocated part, so we can run a well-defined common allocation. Shortly I expect to be able to say been there, done that. I have seen (not in MANET) IANA allocate even at the Internet Draft stage, but I don't know how you persuade anyone to do that (nor do I care to do it).

All of which I think is pretty much consistent with Stan's coffee pot extension, which went through these stages.

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

> On 19 Jun 2015, at 20:51, Wiggins, David - 0665 - MITLL <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Jun 2015 09:16:26 -0400

> On 19  Jun 2015, at 12:09 , Ratliff, Stanley <[email-masked]> wrote:
> 

Here is a simpler scenario that allows for radio-unique extensions,
eliminates the need for a 2nd parser (parsing UTF-8 rather than bits)
and is consistent with MANY prior IETF protocols…

Go to IANA and ask them to assign me Experimental-status Data 
Item code point(s) and/or Signal code point(s).

> I also map out how these signals/data items look (e.g., is the DLEP_COLUMBIAN data item 8 bits, 16 bits, or just 1?), and then I start looking for a router vendor to "play nice with me", and support my coffee maker experiment. Assuming I find such a router vendor, we implement the "Coffee Maker Experiment" - and again, since this is *my* scenario, we'll assume that's its wildly successful. All of my beta test sites are "Slurping coffee on the move", and enjoying it. In fact, it's so wildly popular that other modem manufacturers are now discussing bolting coffee makers onto their modems…

Based on working with a large radio manufacturer, I think that in many cases
these additional code points will be either (a) inherently unique to the
particular radio or (b) inherently unique to some property of the radio,
modulation scheme/waveform, frequency bands, or something else physical.

So I doubt that a typical extension would have utility for most folks.

> So, at this point, it's time for me and my router-vendor partner to approach the MANET WG with a draft describing the Coffee-Maker "Experiment" as a DLEP "Extension". And true to form, the WG debates the weighty issues (e.g., Should there be a DLEP_ARABICA data item? NO! YES! Wait! We should allow it to MAKE TEA! Yes, that's the ticket! It MUST [proper homage to RFC 2119] contain a DLEP_EARL_GREY data item!), ad-nauseum, over a period of time that you thought would take a couple of IETF meetings, but actually spans about 5 years (in other words, you *thought* it was going to be a project, but it turned into a career path)…

Using Stan’s approach, we get to throw away the running code (because it is UTF-8
rather than using bits) and an entirely new data element or signal gets added.

Users now have to wait for (a) the existing radio vendor to implement the new 
things and (b) the existing router vendor(s) to implement the new things and (c) 
interoperability issues to be sorted out between the various new implementations.

Alternatively, if we have a single extensions mechanism, and if the party that
obtained the extension codes from IANA thinks it is more broadly useful, 
then that party can publish an Informational status or Experimental status
RFC (e.g. on the RFC-Editor track, without a lot of process overhead).

With this approach, we avoid having 2 parsers (bits vs UTF-8), we have
enough Data Item space and Signal space for the foreseeable future
(8-bits is too small even if one assumes Stan’s concept), and we avoid
a totally gratuitous period of re-inventing the wheel using bits
instead of UTF-8.

Things that are useful and openly specified get deployed, regardless 
of their IETF status.

Of course, if radio designer A and radio designer B happen coincidentally
to each design different approaches to the same underlying technology 
issue, nothing prevents one or both (or some user or some router vendor)
from proposing that the appropriate WG (MANET for now) create a standard
Data Item or standard Signal for the situation at hand.

> Finally, clearing Working Group Last Call (and *then* getting a crap-ton of really useful comments, because apparently, no one reads these things unless/until there's supposedly no chance to change…

This is WAY WAY too complex, and the change of syntax between “Experiments”
and “Extensions” is totally gratuitous (value subtract), and it is unrealistic.

For both physics reasons and technology reasons, there will be some Data Items 
(and maybe some Signals) that are inherently tied to the particular radio, 
waveform, frequency band, or what have you.

Purely as an example, there is an OpenGroup consortium called DirecNet (TM)
that are developing an open-standards radio specification that would be
useful for 1st responders.  Having some waveform-specific Data Items 
would be helpful for most waveforms. (Caveat: While I am aware of DirecNet, 
and I have attended a meeting or two, my client is NOT a member of DirecNet.)

> But my point here is, that all the while, my customers have been merrily "slupring coffee on the move, and enjoying it" - utilizing the "Experimental" TLVs gives me (us, actually) the ability to ac…

But the approach you outline doubles the work versus simply publishing an
Informational or Experimental status RFC once things are sorted out fully.

> ...and that was the motivation behind having both "Experimental" TLVs, and a documented "Extension" mechanism... 

I appreciate the explanation.  I understand the reasoning.  I don’t
think that is a good approach.  The additional complexity, including
but not limited to having an entire 2nd parser, is too much and
the approach is not likely to work well given the real-world constraints.

I would like to see a more conventional IETF approach where we have an 
obviously large enough code space for Data Items and for Signals, and 
have an ability to have both standard and non-standard Data Items and 
Signals added over time as appropriate.

Yours,

Ran Atkinson

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Jun 2015 09:21:00 -0400

> On 19  Jun 2015, at 12:17 , Henning Rogge <[email-masked]> wrote:
> 

At present the “number space” of 8-bits for Data Items is already too
small — even assuming the approach Stan outlined in his earlier note.

We need to move to 16-bits for these 2 fields, regardless of the 
“extension approach” taken.  

Adding a 2nd parser for UTF-8 is avoidable complexity.  The usual
IETF approach is to do as David Wiggins suggested, splitting the
number space into distinct Standards-track and Experimental subsets,
both of which are allocated by IANA (albeit using 2 different
allocation policies).  Standards-track subspace would use an IETF
Standards-Action required policy for code point allocation.  The
other subspace would use “First Come, First Serve” with “No specification
required” which some other protocols already do; it works just fine.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Jun 2015 09:32:33 -0400

> On 19  Jun 2015, at 13:50 , Ratliff, Stanley <[email-masked]> wrote:
> 
> David,
> 

Using a single extension approach would result in a very fine standard, 
because it ensures that DLEP is extensible and won’t need to be redone 
in a few years because the extensibility was too limited/constrained.
It also improves interoperability chances because we eliminate the
gratuitous UTF-8 parser from all DLEP implementations.

256 standard extensions is likely not enough given the wide range of
different radio types in use somewhere on the planet — and the rate of
growth in different waveforms and radio types and so forth.  

32K extensions is almost certainly larger than we need.  I suppose 
we could go with a 12-bit field or such like, but alignment benefits 
suggest either an 8-bit field (too small) or a 16-bit field (more than 
adequately large).

> 2. I don't believe IANA operates that way. They need a WG-approved document
> in order to start the assignment process. 

This is an incorrect understanding.  IANA supports a range of different
allocation policies.  Each RFC that creates a new protocol number space
is required to specify the allocation policies to use precisely BECAUSE 
IANA supports a range of different policies.  If IANA only had one supported
allocation policy, that guidance would not be needed.

IANA operates the way you describe ONLY IF the RFC-specified allocation policy 
is to require an IETF WG-approved document.  IANA can and does manage various 
other protocol spaces (most obvious example: TCP/UDP port numbers) using 
“First Come, First Served” with “No specification required”.

David Wiggins’ approach is a very good one.  Increase the number space
and split the number space.  Make one segment “standards-track” with an 
IETF standards-track RFC required for code point allocation from IANA.  
Make the other segment “Experimental” with “First Come, First Served” 
code point allocation from IANA and “specification not required”.

Yours,

Ran Atkinson

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 20 Jun 2015 09:58:41 -0400

> On 19  Jun 2015, at 17:12 , Christopher Dearlove <[email-masked]> wrote:
> 
> First, when we allocate a number space, we typically allocate some numbers for private or experimental use. (Those two aren't exactly the same, but close enough for these purposes.) Essentially I shouldn't let things using those numbers escape onto the wider Internet, they should be confined to my network.

In my nearly 30 years of IETF experience, the above is not necessarily the case.  

There are at least 3 scenarios that one can see if one surveys the set
of IETF standards-track protocols, and probably more than that.

GIVEN:  Standards-track numbers are allocated by IANA upon publication
        approval for a standards track RFC.  On rare occasions, early
        allocation from IANA will happen for a standards-track I-D 
        when IESG believes it is beneficial to do so.

A.  The “private” or “experimental” use numbers are NOT allocated by IANA
    at all, instead being shared on a non-controlled basis, in which case
    packets with those code point values ought not escape one’s administrative 
    domain.  

B.  Some “private” use numbers are allocated “First Come, First Serve” with
    “no specification required”.

C.  A hybrid of scenarios A & B.  In this case there are 3 different code
    point subsets:
	(1) standards-track
	(2) private use & allocated by IANA
	(3) experimental use within one’s own administrative domain,
            not allocated by IANA, and “its your problem if you have
            2 different implementations” for a given code point value

The proposal here is (B), but (C) also would be acceptable.  

If (C) is adopted rather than (B), then I’d make the (C3) pool 
relatively small (maybe in the range of 8-32 code points).

I’d like to see:
————————
- more than 8-bits for code points (signals & data items)
- 2 different subsets of code points for each 
- a standards-track code point set that are allocated by IANA upon
  publication of an IETF standards-track RFC
- private use code points allocated by IANA “First Come, First Served”
  with “no specification required”.

> And on my network I can do what I like. You can use the same number in that space for something completely different in your network. Those numbers aren't allocated. Typically the rest are allocated by IANA (usually subject to some sort of review process, which makes it not quite first come first served).

“Expert Review” is another option, in ADDITION to “standards-track RFC
required” and “First Come, First Served”.

Normally, one uses “Expert Review” either as a work-around for an overly 
small set of code points (which bug some of us are trying to avoid here)
OR because the protocol was badly designed such that an unrecognized
code point causes the protocol behavior to be unspecified/underspecified
and implementations are likely to crash horribly (again, something this
WG should avoid with DLEP).

As I have said, there are a range of existing IANA allocation approaches
that can be used in an IETF protocol.

> We may then progress to an RFC. Which might be experimental or a Proposed Standard (it could also be informational, but I won't go there). Obviously in the standard case we should be able to use it…

The difference between Informational RFC or Experimental RFC sometimes
seems subtle.  If a code point definition might be “risky” for the
network health, then “Experimental” is preferable to “Informational”
and the risk ought to be clearly described (see NETBLT).  

In non-risky cases, either RFC status would be a reasonable choice.
Informational RFC is likely better if the goal is to encourage others 
to use one’s private extension.

Justin (with your WG Chair Hat On, please):

If it is useful, I am happy to draft up some candidate IANA Considerations
text for the list to evaluate, on the assumption that we increase the
code point size to 16-bits.  My plan would be to borrow and wordsmith
text from other IETF standards-track RFCs in doing this, not to tread
new ground.  (There is no need for the WG to tread any new ground to do 
what David and I believe is right.)

Yours,

Ran

---

From: Justin Dean <[email-masked]>
Date: Sat, 20 Jun 2015 14:38:30 +0000

Ran there is another issue which comes frome a very large first come first
serve assignments space. There is little/no incentive to standardize in the
standard space and we end up with a bunch of DLEP radios with very limited
interoperability support with other vendor DLEP routers. The text based
approach was a compromise to help "solve" this issue, if I'm remembering
correctly. Propsoed text would be fine but I the main issue was/is the
confusion regarding the roles of the different types as presented in the
draft. I see value in both approaches.

Justin Dean

On Sat, Jun 20, 2015, 9:58 AM RJ Atkinson <[email-masked]> wrote:

> > I'm not claiming to be an authority, but I've had some experience. This
> is my observation of how I've seen things work, rather than anything
> official. As such if, for example, someone comes along and points out that
> I've misstated something, with proper references, believe them not me.
> >
> > And I also realise this is a post which many will see as teaching egg
> sucking. Those who do, please do improve on it.
> >
> > First, when we allocate a number space, we typically allocate some
> numbers for private or experimental use. (Those two aren't exactly the
> same, but close enough for these purposes.) Essentially I shouldn't let
> things using those numbers escape onto the wider Internet, they should be
> confined to my network.
>
> > And on my network I can do what I like. You can use the same number in
> that space for something completely different in your network. Those
> numbers aren't allocated. Typically the rest are allocated by IANA (usually
> subject to some sort of review process, which makes it not quite first come
> first served).
>
> > We may then progress to an RFC. Which might be experimental or a
> Proposed Standard (it could also be informational, but I won't go there).
> Obviously in the standard case we should be able to use it publicly. I'm
> not sure what the exact rules are in the experimental case, but I would
> assume we should at the least be very wary of letting things out or not do
> so at all depending on the next point.
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 09:21:42 +0000

Okay, I'm back and I'm jumping in on this one with my author hat on...

The historical reason for both Experiments and Extensions are:

1) We tried it a different way - 'Optional Data Items supported (and 
friends)' and everyone hated it.

2) There was general consensus that DLEP should be extensible so that 
progress could be made standardizing the core functionality without 
preventing further good work becoming 'standard extensions' at a later date.

3) Implementers wanted some 'local administratively scoped' sandbox for 
their own experiments, prior to approaching the IETF.

4) The reason for strings is avoid clashes (like a GUID).  We previously 
recommended registered IEEE EUIDs, but strings were viewed as simpler 
and less restrictive, i.e. You don't need to pay IEEE.

The reasoning behind the Experiments are:

Most current DLEP router implementations talk to multiple radios at 
once, and sometimes experimental features are exposed by either peer. 
In this use-case it must be possible for the router to advertise to all 
radios that it is willing to process Vendor-X experiments *and* Vendor-Y 
experiments, while the experiment is being performed, *before* taking 
the results to the IETF, because it is still an experiment.

Hence:  A DLEP peer MUST be able to advertise support for multiple 
experiments, but it is up to the implementer how to handle clashes of 
ids in the experimental range.

The reason for using a textual identifier for an experiment is the other 
requirement: Experiment ids SHOULD be scoped locally, there is no 
appetite for grabbing an id from some IANA list, registering it for 
posterity, etc. just for a quick experiment.  That is Extensions.  With 
text, one can just use one's make and model name, e.g. "Stan's Coffee 
machine experiment" is good enough, iff I am talking to Stan's radio in 
my lab; it is unlikely that John's tea machine will unintentionally 
advertise an identical experiment id.

As a side note on strings, the UTF8 requirement is there so that the 
strings may be output to somewhere user readable.  As far as any 
processor is concerned, octet by octet compare is all that is required: 
memcmp() is enough, no UTF parser needed.  A potential criticism would 
be that non-printable characters are allowed in the draft currently.  If 
UTF8 seems too lose, then let's use [A-Za-z0-9_], but strings are there 
for a good reason.  A counter argument is adding extra restrictions on 
the format of the text adds processing requirements on the peer.

Adding more signal and data item ids for experiments is irrelevant, the 
critical question is how do two peers identify experiments about which 
they can negotiate support?  Our proposed solution: unique strings.

In summary:  There is a good reason for the split between Experiments 
and Extensions.  They cover two different use-cases that are in use 
today.  We have chewed this over thoroughly, and although it seems that 
we have proposed a 'dog's breakfast' solution, it is actually backed by 
good reasoning.

By contrast, Extensions are modelled on the SMTP mechanism (but using 
numeric ids).  There MUST be a document that has passed through the 
IETF.  IANA MUST assign a unique numeric ID.  A peer may implement zero 
or more Extensions as it sees fit.  The end.

Hope that helps,

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 22 Jun 2015 09:49:58 +0000

No, not necessarily the case, as I indicated. But most of the protocols I've observed have more control than a free for all in IANA allocated space, plus an experimental space (not the same as an experimental protocol as you know but I though another post muddled) that is privately used. That pattern works well and reduces problems.

What problems? Look at it from the perspective of users, which includes the company I work for. They/we would want to buy DLEP-enabled radios, and DLEP-enabled routers, independently, and have them work together. Unfortunately that's not always as straightforward as it ought to be, but my belief is that some review/control over the creation of new TLVs would make that more likely, while a free for all first come first served in a large space would make it less likely.

In other words, C on your list, which is what I described, without C2. The last protocol I looked at with a C2 IANA registry it was empty after many years of existence. And C2 is worse when you have two types of equipment (radios and routers) talking to each other, rather than one type (routers running a routing protocol) and from different manufacturers. Anything in C2, why not make it in C1?

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: 20 June 2015 14:59
To: [email-masked]
Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
This message originates from outside our organization, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For additional information about Spearphishing, click here <http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>. If you feel the email is suspicious, please follow this process. <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>

There are at least 3 scenarios that one can see if one surveys the set of IETF standards-track protocols, and probably more than that.

If (C) is adopted rather than (B), then I’d make the (C3) pool relatively small (maybe in the range of 8-32 code points).

I’d like to see:
————————

> And on my network I can do what I like. You can use the same number in that space for something completely different in your network. Those numbers aren't allocated. Typically the rest are allocate…

“Expert Review” is another option, in ADDITION to “standards-track RFC required” and “First Come, First Served”.

Normally, one uses “Expert Review” either as a work-around for an overly small set of code points (which bug some of us are trying to avoid here) OR because the protocol was badly designed such that an unrecognized code point causes the protocol behavior to be unspecified/underspecified and implementations are likely to crash horribly (again, something this WG should avoid with DLEP).

As I have said, there are a range of existing IANA allocation approaches that can be used in an IETF protocol.

> We may then progress to an RFC. Which might be experimental or a Proposed Standard (it could also be informational, but I won't go there). Obviously in the standard case we should be able to use it…

The difference between Informational RFC or Experimental RFC sometimes seems subtle.  If a code point definition might be “risky” for the network health, then “Experimental” is preferable to “Informational”
and the risk ought to be clearly described (see NETBLT).  

In non-risky cases, either RFC status would be a reasonable choice.
Informational RFC is likely better if the goal is to encourage others to use one’s private extension.

Yours,

Ran

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Jun 2015 14:51:04 -0400

Stan,
> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" (the experiments), and the more formal Extensions mechanism, which by necessity, starts with an IETF draft. 

I believe the fairly typical way other protocols deal with this issue is
via proper IANA allocation policies, see rfc5226. For example the single
extensions field can be defined to have a range, say 1-N with one policy
and another range, say N-M with another policy.

Based on the discussion I'd suggest :
0,<max value>    Reserved
1-N                        "Standards Action" (for Standards Track
documents) and
                                "Specification Required" (for other
documents, including experimental)
                            (The registry allows a request to indicate
which policy applies)
N-<max value-1>    Private Use

I think the private use space should be pretty small.
I'd also increase the Extension filed to be larger, as 256 seems pretty
small assuming the protocol has any level of success/long life.

Lou

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 22 Jun 2015 16:51:57 -0400

> On 22  Jun 2015, at 14:51 , Lou Berger <[email-masked]> wrote:
> 
> 
> Stan,
>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox”
>> (the experiments), and the more formal Extensions mechanism,
>> which by necessity, starts with an IETF draft. 
> 
>                             documents) or "Specification Required”
>                            (for other documents, including experimental)
>                             which policy applies.)
> I'd also increase the Extension filed to be larger,
> as 256 seems pretty small assuming the protocol has
> any level of success/long life.
> 
> Lou

I agree that something along the lines of what Lou proposed above 
seems like a reasonable basis for a compromise.  

I concur that 256 is too small a number for <max value>.

Quoting from RFC 5226, Section 4.1, Page 10:

 "Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification and
            evaluate whether it is sufficiently clear to allow
            interoperable implementations.  The intention behind
            "permanent and readily available" is that a document can
            reasonably be expected to be findable and retrievable long
            after IANA assignment of the requested value.  Publication
            of an RFC is an ideal means of achieving this requirement,
            but Specification Required is intended to also cover the
            case of a document published outside of the RFC path.  For
            RFC publication, the normal RFC review process is expected
            to provide the necessary review for interoperability, though
            the Designated Expert may be a particularly well-qualified
            person to perform such a review.

            Examples: Diffserv-aware TE Bandwidth Constraints Model
            Identifiers [RFC4124], TLS ClientCertificateType Identifiers
            [RFC4346], ROHC Profile Identifiers [RFC4995]."

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 08:27:29 +0000

Comments inline...

>              [RFC4346], ROHC Profile Identifiers [RFC4995]."

Okay, this seems sensible, given we expand the id bits to 16, and have 
no special 0 value, then we can have a registry for data items and a 
second for signals, like so:

0 - M:     IANA allocated, DLEP 'core' ids (from this soon-to-be-RFC)
M - N:     Reserved for IANA allocated Extensions ids (as they arrive)
N - 0xFFF: Private space, reserved for Experiments.

M is 26 for data items, and 16 for signals.

I am thinking, that N should be 0xFF00.

How's that?

Rick

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 23 Jun 2015 13:33:25 +0000

> From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
> Sent: Tuesday, June 23, 2015 4:27 AM
> To: RJ Atkinson; [email-masked]
> >>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox"
> >>> (the experiments), and the more formal Extensions mechanism, which
> >>> by necessity, starts with an IETF draft.
> >>
> >> I believe the fairly typical way other protocols deal with this issue
> >> is via proper IANA allocation policies, see rfc5226. For example the
> >> single extensions field can be defined to have a range, say 1-N with
> >> one policy and another range, say N-M with another policy.
> >>
> >>                              documents) or "Specification Required"
> >> I'd also increase the Extension filed to be larger, as 256 seems
> >> pretty small assuming the protocol has any level of success/long
> >> life.
> >>
> >> Lou
> >
> Okay, this seems sensible, given we expand the id bits to 16, and have no
> special 0 value, then we can have a registry for data items and a second for
> signals, like so:
> 

I think the private space is too large. IMO, it shouldn't be any larger than 5. 

Regards,
Stan

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 13:34:10 +0000

Hi Lou,

I like this direction as a replacement for the experiment string.  I think
a unified mechanism simplifies understanding of the protocol.  It seems
like the implementation would be simpler too, since you don't have to make
two different extension mechanisms play well together.  A few questions
below...

On 6/22/15, 2:51 PM, "Lou Berger" <[email-masked]> wrote:

>>(the experiments), and the more formal Extensions mechanism, which by
>>necessity, starts with an IETF draft.
>
>                 documents) and "Specification Required" (for other
>                 (The registry allows a request to indicate which policy
>applies)

The Reserved range above encompasses the entire range (I'm assuming <max
value> refers to the same value in the 1st and 3rd case).  So I'm not
clear on the sense of "Reserved" here.

For the Private Use range, which policy (from Ran's message a few days
ago) do these follow? :

  A.  The ³private² or ³experimental² use numbers are NOT allocated by IANA
  at all, instead being shared on a non-controlled basis, in which case
  packets with those code point values ought not escape one¹s
administrative 
  domain.  

  B.  Some ³private² use numbers are allocated ³First Come, First Serve²
with
  ³no specification required².

  C.  A hybrid of scenarios A & B.  In this case there are 3 different
code 
     point subsets:
    (1) standards-track
    (2) private use & allocated by IANA
    (3) experimental use within one¹s own administrative domain,
        not allocated by IANA, and ³its your problem if you have
        2 different implementations² for a given code point value

I like C (except Private Use would not include standards-track); you get a
little bit of everything.

David

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jun 2015 10:07:25 -0400

David,
    See below.

On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:
> value> refers to the same value in the 1st and 3rd case).  
There was comma there.  Let me try this:
0                        Reserved
<max value>    Reserved

> So I'm not clear on the sense of "Reserved" here.
https://tools.ietf.org/html/rfc5226#section-4

      Reserved:  Not to be assigned.  Reserved values are held for
            special uses, such as to extend the namespace when it become
            exhausted.  Reserved values are not available for general
            assignment.

> little bit of everything.

The terms I used are also defined in rfc5226

      Standards Action - Values are assigned only for Standards Track
            RFCs approved by the IESG.

            Examples: BGP message types [RFC4271 <https://tools.ietf.org/html/rfc4271>], Mobile Node
            Identifier option types [RFC4283 <https://tools.ietf.org/html/rfc4283>], DCCP Packet Types
            [RFC4340 <https://tools.ietf.org/html/rfc4340>].

      Specification Required - Values and their meanings must be

            Examples: Diffserv-aware TE Bandwidth Constraints Model
            Identifiers [RFC4124 <https://tools.ietf.org/html/rfc4124>], TLS ClientCertificateType Identifiers
            [RFC4346 <https://tools.ietf.org/html/rfc4346>], ROHC Profile Identifiers [RFC4995 <https://tools.ietf.org/html/rfc4995>].

      Private Use - For private or local use only, with the type and
            purpose defined by the local site.  No attempt is made to
            prevent multiple sites from using the same value in
            different (and incompatible) ways.  There is no need for
            IANA to review such assignments (since IANA does not record
            them) and assignments are not generally useful for broad
            interoperability.  It is the responsibility of the sites
            making use of the Private Use range to ensure that no
            conflicts occur (within the intended scope of use).

            Examples: Site-specific options in DHCP [DHCP-IANA <https://tools.ietf.org/html/rfc5226#ref-DHCP-IANA>], Fibre
            Channel Port Type Registry [RFC4044 <https://tools.ietf.org/html/rfc4044>], Exchange Types in the
            IKEv2 header [RFC4306 <https://tools.ietf.org/html/rfc4306>].

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jun 2015 10:23:04 -0400

Rick,

See below.

> N - 0xFFF: Private space, reserved for Experiments.
I would not use the word experiments here as it has a specific meaning
to iana.  The "Private" policy as defined in rfc5226 should suffice. no?

> M is 26 for data items, and 16 for signals.

Given that signal values and data item values are carried in separate
fields they are their own number spaces and should have their own
registries.  Assignment in each should start at 1. (1-16 for signals,
1-26 for data items.)  To avoid issues in the long term, a single number
base should be used (i.e., base 10).

Lou

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Jun 2015 10:58:47 -0400

> On 23  Jun 2015, at 04:27 , Rick Taylor <[email-masked]> wrote:
> 
> no special 0 value,

I’m not sure what “no special 0 value” means just above.

My understanding of Lou’s proposal was that both 0 and
max-value would be Reserved — as in not allocated/used.
This is quite common in IETF standards-track protocols.

> then we can have a registry for data items and a 

Under Lou’s proposal, any IANA allocated Extension ID either
(A) would be IETF standards-track or (B) would be “Specification
Required” so anyone could implement it and be interoperable.

With his proposal, it becomes trivial to move a non-standard
extension into a standard extension — simply publish an RFC
saying that extension with ID=X is now standards-track —
without needing to change ANY code in ANY existing implementation.
That has real interoperability advantages.

So I don’t see a value in separating these numeric ranges.
With a 16-bit Data Item space, we don’t need to separate them out.

> N - 0xFFF: Private space, reserved for Experiments.

Hmm.  Can we please discuss this using integers, as is
commonly done in standards-track RFC IANA Considerations
sections, rather than discussing using a mixture of 
integer and hexadecimal notations ?

> I am thinking, that N should be 0xFF00.

I am confused about precisely what is being proposed above,
given the mixture of hex and decimal notations.

For now, I prefer Lou’s proposed approach, in part because
I believe I understand what he is proposing.

Yours,

Ran

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 15:00:06 +0000

>There was comma there.  Let me try this:

Yes, that was my confusion.  You're reserving two values, not the whole
range.

>The terms I used are also defined in rfc5226

I plead guilty for not having read 5226, so the excerpts are helpful.
Thanks.  I guess we can do without the "no specification required, but
still IANA-registered" option.

David

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 15:40:38 +0000

First, apologies for mixing hex and decimal.

Following from Lou's RFC5226 guidance:

For data item ids:

0           -  Reserved
1-20        -  Standards Action - DLEP core
21-23       -  Standards Action - Credit windowing
24-65519    -  Specification Required - space for future Extensions
65520-65534 -  Private Use - space for Experiments
65535       -  Reserved

For signal ids:

0           -  Reserved
1-16        -  Standards Action - DLEP core
17-65519    -  Specification Required - space for future Extensions
65520-65534 -  Private Use - space for Experiments
65535       -  Reserved

For Extension ids:

0           -  Reserved
1           -  Standards Action - DLEP Credit Windowing
17-65534    -  Specification Required - future Extension ids
65535       -  Reserved

Experiments MUST use the Private Use area.  Extensions MUST use the 
Specification Required area.

Hope that's clearer?

Rick

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 23 Jun 2015 15:43:14 +0000

Rick, 

I'm still of the opinion that the private-use space is too large. 

Regards,
Stan

> From: Rick Taylor [mailto:[email-masked]]
> Sent: Tuesday, June 23, 2015 11:41 AM
> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ Atkinson;
> [email-masked]
> > Yes, that was my confusion.  You're reserving two values, not the
> > whole range.
> >

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 15:47:11 +0000

Oops, cut'n'paste problem!

Should be:

For Extension ids:

0           -  Reserved
1           -  Standards Action - DLEP Credit Windowing
2-65534     -  Specification Required - future Extension ids
65535       -  Reserved

Sorry

Rick

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Jun 2015 17:48:18 +0200

Stan,

my "layer 2 frame statistics" would need (if I want to transmit
everything) 8 or 10 data items... the "layer1 data export" is I think
6 or 8 data items.

I think 15 TLV types for experiments is not that much. It might not
even be enough to run both of my experiments at the same time.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 15:50:17 +0000

Stan,

I'm not convinced.  If we put in the effort to allow (possibly multiple) 
experiments, we may as well give them enough room to run them.

I would personally like to give them more than 14 ids. 254 seems more 
generous, but I know you are worried about being too 'loose'.

Rick

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 15:51:43 +0000

I think we need some Private Use extension ids too.

David

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 15:56:29 +0000

> I think we need some Private Use extension ids too.

No, Extensions are Specification Required by design.  Experiments are 
provided for Private Use id use.

Rick

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 15:57:38 +0000

I also think the private space is too small.  The effect could be to force
people to encroach on the Specification Required space to get more
Privates, making the division meaningless.  254 would probably be enough,
though I'm not really seeing the harm in making it even larger.

David

---

From: Rick Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 16:25:00 +0000

The original reasons for having a very small Private Use space were:

1) We only had 256 ids.

2) We didn't want experiments to become de-facto Extensions.

3) We were worried that a more generous Private Use space would set of 
alarm bells at the draft passed through the various review stages.

Now with the wider id field, 1) is now irrelevant, but we need guidance 
on 3), and 2) might be impossible to solve.

Lou, do you have a comment?

Rick

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jun 2015 12:36:57 -0400

Rick,

> Lou, do you have a comment?
I suspect that some relatively small number, say in the small 100s, of
private use values is unlikely to cause too many question.  Keep in mind
that private use is not the same as experimental use from the
IANA/process perspective:

I don't think a specific experimental use range/policy serves much value
as it complicates transition from experiment to standard - and the
specification required policy can support experimental non-private usage.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jun 2015 13:14:31 -0400

Rick,
    Specific values need to be provided for delp defined registries.  I
think you have :

Registry: DLEP Signal Type
    Range       Registration Procedures   
    ---------   --------------------------------
    0-N, M      Standards Action or Specification Required
    N-(M-1)     Private Use

    Value       Use
    -------     -------------------------------
        0       Reserved
        1       Peer Discovery
        2       Peer Offer
        3       Peer Initialization
        4       Peer Initialization ACK
        5       Peer Update
        6       Peer Update ACK
        7       Peer Termination
        8       Peer Termination ACK
        9       Destination Up
        10      Destination Up ACK
        11      Destination Down
        12      Destination Down ACK
        13      Destination Update
        14      Heartbeat
        15      Link Characteristics Request
        16      Link Characteristics ACK
        17-N    Unassigned
        N-(M-1) Private Use
        M       Reserved

Registry: DLEP Data Item Type

    Range       Registration Procedures   
    ---------   --------------------------------
    0-N, 65535  Standards Action or Specification Required
    N-65534     Private Use

    Value       Use
    -------     -------------------------------
        0       Reserved
        1       Status
        2       IPv4 Connection Point
        3       IPv6 Connection Point
        4       Peer Type
        5       Heartbeat Interval
        6       Extensions Supported
        7       Experimental Definition
        8       MAC Address
        9       IPv4 Address
        10      IPv6 Address
        11      IPv4 Attached Subnet
        12      IPv6 Attached Subnet
        13      Maximum Data Rate (Receive) MDRR)
        14      Maximum Data Rate (Transmit) (MDRT)
        15      Current Data Rate (Receive) (CDRR)
        16      Current Data Rate (Transmit) (CDRT)
        17      Latency
        18      Resources (Receive) (RESR)
        19      Resources (Transmit) (REST)
        20      Relative Link Quality (Receive) (RLQR)
        21      Relative Link Quality (Transmit)(RLQT)
        22      Link Characteristics ACK Timer
        23      Credit Grant
        24      Credit Window Status
        25      Credit Request
        26-N    Unassigned
        N-65534 Private Use
        65535   Reserved

Registry: DLEP Extension Type

    Range       Registration Procedures   
    ---------   --------------------------------
    0-N, 65535  Standards Action or Specification Required
    N-65534     Private Use

    Value       Use
    -------     -------------------------------
        0       Reserved
        1       Credit-Windowing
        2-N     Unassigned
        N-65534 Private Use
        65535   Reserved

Lou

---

From: Justin Dean <[email-masked]>
Date: Tue, 23 Jun 2015 13:17:30 -0400

Private use in the 100-200 range seems appropriate to me.  It should be
large enough to provide space for multiple experiments to be run at the
same time but not so large that number collisions wouldn't be a worry.
Pushing people who use/create these extensions to document/specify and grab
an official code point.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Jun 2015 13:39:25 -0400

> On 23  Jun 2015, at 11:43 , Ratliff, Stanley <[email-masked]> wrote:
> 
> Rick, 
> 

Stan,

I think it is far far too small.  There needs to be a reasonably
large private use space, particularly since a single type value
now is used for a single datum, whereas with the former
Experimental value a single type could be used for many data items.

If someone is experimenting, for example with a prototype radio,
one might concurrently want to experiment with (for example)
more precise metrics, alternative queueing/precedence strategies,
and wave-form-specific data items concurrently to see how the
combination(s) work together.

With PPPoE, there are a LOT of code points available for experimentation
at present.  If DLEP has prohibitively private use spaces, then
there is a strong incentive to use PPPoE instead of DLEP.  
How is that a good outcome for the IETF or for this WG ?

I’d suggest about 200 Private Use values for Data Items.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Jun 2015 13:43:17 -0400

> On 23  Jun 2015, at 11:56 , Rick Taylor <[email-masked]> wrote:
> 

Rick,

  Your answer appears to refer to draft-14, rather than Lou
Berger’s proposal.

  However, I suspect David is talking about the Lou Berger proposal,
and I think that he means that the DLEP spec needs a reasonably 
large “Private Use” space that can be used for Experiments (again, 
in the context of Lou’s proposal).  Please also see Henning Rogge’s note 
from today at 11:48 US EDT.

  If your quoted text above meant something other than those 2 candidates,
I was not able to puzzle your meaning out.  Please rephrase.

Thanks,

Ran

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 23 Jun 2015 18:05:56 +0000

Ran,

> Sent: Tuesday, June 23, 2015 1:39 PM
> To: [email-masked]
> I think it is far far too small.  There needs to be a reasonably large private use
> space, particularly since a single type value now is used for a single datum,
> whereas with the former Experimental value a single type could be used for
> many data items.
> 

I believe the discussion is now centering around 3 different name/number spaces:  (1) Data Items, (2) Signals, and (3) Extensions. I can see a need for a larger private use space in the data items registry than for the signals registry, for example. So I believe we'll wind up with different allocations, for the 3 different registries. From what I gather in your note, it seems that you are more interested in the size of the private use data item space. Did I get that correct? If not, please advise.

In any event, I believe that a driving principle for the allocations is what Justin Dean stated: "... Pushing people who use/create these extensions to document/specify and grab an official code point." Hence, my desire to restrict the size of private use allocations to the bare minimum.

> If someone is experimenting, for example with a prototype radio, one might
> concurrently want to experiment with (for example) more precise metrics,
> alternative queueing/precedence strategies, and wave-form-specific data
> items concurrently to see how the
> With PPPoE, there are a LOT of code points available for experimentation at
> present.  If DLEP has prohibitively private use spaces, then there is a strong
> incentive to use PPPoE instead of DLEP.

From the perspective of someone who is a co-author of RFC 5578 (PPPoE Extensions for radio-based traffic), I can tell you that there are *a lot* of other reasons to avoid PPPoE like the plague... ;-)

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Jun 2015 20:13:29 +0200

> I believe the discussion is now centering around 3 different name/number spaces:  (1) Data Items, (2) Signals, and (3) Extensions. I can see a need for a larger private use space in the data items…

Yes... "a lot of" private data items... some private signals...

and (if any) only a few "private" extensions.

Otherwise we will see lots of propietary Extensions with no will to
move to the IETF.

> From the perspective of someone who is a co-author of RFC 5578 (PPPoE Extensions for radio-based traffic), I can tell you that there are *a lot* of other reasons to avoid PPPoE like the plague... ;…

I know a few people who talked about a "multicast adapter" for PPPoE
radios... not sure if it ever worked well. ;)

Henning

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Jun 2015 14:41:22 -0400

> On 23  Jun 2015, at 14:05 , Ratliff, Stanley <[email-masked]> wrote:
> 
> I believe the discussion is now centering around 3 different name/number spaces:  
> (1) Data Items, (2) Signals, and (3) Extensions. 

Stan,

If that is the case, I am confused by your current node,
and might not have understood Lou’s most recent note.

I have thought we were talking about "Data Items” alone just now, 
and segmenting that number space into multiple chunks with (a) some 
Reserved outright and (b) a number space that is BOTH pre-defined 
Data Items and future extensions to Data Items and (c) a different 
number space reserved for Private Use.  I also thought we were 
talking about possible size ranges for the several different
chunks of Data Item number space.

Lets back up one step in hope of clarity.  In your mind, how is a 
Data Item fundamentally a different animal from an Extension ?  
Whether it is defined in the base DLEP RFC ?

Signals are worthy of discussion, and I recognize that Lou has
mentioned them, but I have been trying to hold off on that topic
for now, in hope of avoiding the cross-threading that seems already 
to have occurred.  It might help clarify discussion if we updated 
subject lines and tried to separate the threads of discussion.

Yours,

Ran

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jun 2015 14:50:59 -0400

Ran,

> and might not have understood Lou’s most recent note.

I'm not sure what you are referring to, but I think the draft requires
the 3 new registries mentioned above in addition to the Status Code
registry already mentioned in the draft.

> chunks of Data Item number space.
One of the other messages brought in the other two registries and I did
reply to that and I think this is what Stan is referring to.

> for now, 
That's fair.
> in hope of avoiding the cross-threading that seems already 
> to have occurred.  
Correct ;-)

Lou
> It might help clarify discussion if we updated

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 23 Jun 2015 21:06:02 +0000

Hi Rick,

>provided for Private Use id use.

Are Experiments specified by the Experiment Name (string) data item, or
are you replacing that with something else?

David