Subject: Re: [6tisch] #41 (minimal): intended status for draft minimal (was: internded status for draft minimal)

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2015 14:21:19 +0200

Xavier Vilajosana writes:
> 4) minimal defines when EBs are sent and what information from the wide set of
> options (IEs) provided by 15.4 TSCH is sent in an EB. 

I.e. provides profile for 15.4 to be used in 6tisch. 

> 5) it defines the specific 15.4 header settings so 2 nodes can talk together
> and establish an initial configuration without discarding frames from one and
> another.

Again profiling. 

> 6) it defines the number of security keys that are needed.

The actual keys do not belong to this document. If you are trying to
say that this document profiles 802.15.4 security by telling that we
use two different key, one for the EBs and one for the rest of the
data, then this is again profiling. On the other hand it does not
provide the information how those two keys are identified, i.e which
key id mode and key index are used for K1 and K2. It does give example
using Key Identification Mode of 0x01, but there is no text explaining
how device knows what KeyIndex is used for K1 and K2.

> 7) it defines how the routing information is used to hint the network
> structure. That is, how the join priority is used to match the routing
> topology.

Btw, the join priority field in the TSCH Synchronization IE was
renamed to Join Metric in the 802.15.4 revision. This is because term
priority is also used for priority traffic etc, thus using it here too
caused confusion. And also the join metric is not really a priority,
it specifies how far the node sending EBs are from the root, i.e. node
sending EBs is setting join metric to be its parent join metric + 1.

> 8) it defines the default number, default slot-offset, channel offset of the
> cells in the schedule of all nodes in a 6tisch network so the network can be
> easily initiated. It also defines the default timing of the slots and the
> default slotframe length, etc..

It does not however specify are those numbers fixed for the duration
of the network. I.e. can any of those change?

It is clear that some of them cannot be changed without tearing down
the network (timeslot timing, channel hopping sequence), but what
about the number of timeslots in the slotframe, or the number of
scheduled cells, or parameters of those cells. 

> Without that, 2 vendors can be running 15.4e but chances are that they do not
> interoperate. The ETSI/6TiSCH plugtest event corroborated the need of such
> specification so vendors are able to easily interoperate. 

This is true, but that is just the reason I think this document is
more of an profile than a standard. I.e. if gives defaults, limits
some features away, specifies how things are set up etc, so we can
have interoperability. There is nothing there that is not already
specified in the 802.15.4-2015, it is just profiling the use of it.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2015 14:27:43 +0200

Xavier Vilajosana writes:
> In minimal, for example, we say what information to be used in the
> JP field of the Synchronization IE or what specific IEs from all the
> possible set have to be sent in the EB to advertise the network and
> what are their specific values. 

Setting Join Metric is already specified in the 802.15.4-2015. What
IEs are mandatory for TSCH is already specified in the 802.15.4-2015.
The default values are not, so those need to be specified here, but
that is just providing a profile for 802.15.4-2015.
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Dec 2015 13:03:56 +0000

Hello Ralph:

I understand that the 6TiSCH architecture, which describes as an informational the general topologies, the use of RPL and 6LoWPAN, and positions the 6BBR as well, is what you call b). One intent was to back the minimal document with the architecture document so we would not have to place that informational background in the standard.

Minimal operating on 802.15.4, it works with the existing 6LoWPAN HD and ND, and does not need to change or parametrize them to operate as a NBMA mesh. A product that implements minimal will beneficiate from the improvements coming from the work in progress at 6lo to build a larger subnet and save energy with an improved compression. Do we need text to say that?

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: lundi 30 novembre 2015 22:48
> To: [email-masked]
> Cc: Haberman Brian <[email-masked]>
> Subject: Re: [6tisch] #41 (minimal): intended status for draft minimal
> 
> 
> > On Nov 30, 2015, at 12:57 PM 11/30/15, Brian Haberman
> <[email-masked]> wrote:
> >
> > Hi Kris,
> >
> > On 11/30/15 12:47 PM, Kris Pister wrote:
> >> are most "ipv6-over-foo" documents standards track, or something else?
> >>
> >
> > Yes, the ipv6-over-foo documents are standards track. It should be
> > noted that those drafts specifically describe the detailed operation
> > of the
> > IPv6 stack for the foo physical layer. The minimal document seems to
> > be more of a compilation of "set X to Y", where X is already defined
> > in a different specification.
> >
> > Your question does raise an interesting point. Is this document
> > supposed to be the 802.15.4e equivalent of RFC 2464? It certainly
> > doesn't read that way to me.
> 
> I think Brian's observation points to an important decision that the WG needs to
> make about this document.  Is the document intended to be:
> 
> (a) a supplement to an "IP-over-6TiSCH" document, that gives specific
> operational parameters for minimal operation of the IP-over-6TiSCH protocol
> suite; or
> (b) a standalone document that explicitly describes the specific use of all the
> protocols required for minimal operation of 6TiSCH
> 
> In my opinion, the document is currently more (a) than (b).  However, (a)
> requires a completed IP-over-6TiSCH document.
> 
> - Ralph
> 
> >
> > Regards,
> > Brian
> >
> >> ksjp
> >>
> >> On 11/30/2015 9:43 AM, Pascal Thubert (pthubert) wrote:
> >>> Dear all:
> >>>
> >>> I created that issue to follow up on whether standard track is
> >>> really the intention for this document or, as Suresh and Brian
> >>> suggest, we would explore an alternative, BCP or informational.
> >>> At the call, there was a sense that informational was not the right
> >>> path, and that std track was slightly preferred. If that is so, we
> >>> must now make the case in the shepherd writeup and defend it in
> >>> front of the IESG. I would like that we explorein depth the pros and
> >>> cons of each, and we really want all the arguments on the table.
> >>>
> >>> What I have so far:
> >>>
> >>> 1) minimal is a base that we expect will operate in many networks
> >>> since it appears to be needed to build the next stage where
> >>> dedicated time slots can be negotiated. Apparently this pleads
> >>> against informational
> >>> 2) minimal is a recommendation for device builders, as opposed to
> >>> network admin. Apparently this pleads for std track rather than BCP
> >>> 3) minimal defines a way to compute the Rank that cannot be obtained
> >>> with a simple parameter in an existing implementation. The operation
> >>> SHOULD be programmed in the device for interoperation and that
> >>> operation is not specified in a preexisting RFC. This pleads for std
> >>> track
> >>>
> >>> What else?
> >>>
> >>> Pascal
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: 6tisch issue tracker [mailto:[email-masked]]
> >>>> Sent: lundi 30 novembre 2015 13:29
> >>>> To: [email-masked]; Pascal Thubert (pthubert)
> >>>> <[email-masked]>
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [6tisch] #41 (minimal): intended status for draft
> >>>> minimal (was:
> >>>> internded status for draft minimal)
> >>>>
> >>>> #41: intended status for draft minimal
> >>>>
> >>>>
> >>>> --
> >>>> -----------------------------------+-------------------------------
> >>>> -----------------------------------+-----
> >>>>  Reporter:  [email-masked]     |       Owner:
> >>>> [email-masked]
> >>>>      Type:  defect                 |      Status:  new
> >>>>  Priority:  major                  |   Milestone:  milestone1
> >>>> Component:  minimal                |     Version:  1.0
> >>>>  Severity:  Submitted WG Document  |  Resolution:
> >>>>  Keywords:                         |
> >>>> -----------------------------------+-------------------------------
> >>>> -----------------------------------+-----
> >>>>
> >>>> Ticket URL:
> >>>> <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41#comment:2>
> >>>> 6tisch <https://tools.ietf.org/6tisch/>
> >>>> IPv6 over the TSCH mode of IEEE 802.15.4e
> >>> _______________________________________________
> >>> 6tisch mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/6tisch
> >>
> >> _______________________________________________
> >> 6tisch mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/6tisch
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 09:06:11 -0500

> 1) minimal is a base that we expect will operate in many networks since
    > it appears to be needed to build the next stage where dedicated time
    > slots can be negotiated. Apparently this pleads against informational

    > network admin. Apparently this pleads for std track rather than BCP

Not to disagree, but to clarify wording:
    Many applicability statements in for-instance email, or routing or
    enterprise-networking (INT) explain how to deploy/configure a (set of) protocol
    for use in a particular setting. I.e. what parameters to tweak, what
    options to turn on/off.  These are advice operational to operators, and
    do not cause the operator to change their RFP.

    Minimal is something that would appear in an RFP, and is a set of
    requirements to implementors as to which options to build in.  Given the
    constrained nature of devices, those decisions can not be left up to operators.

    > operation is not specified in a preexisting RFC. This pleads for std

Well, this might point towards there needing to be a new ROLL document that
should be on standards track that minimal should reference.

This might still be a good idea.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 09:08:03 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > To start with, TSCH is a 802.15.4 and we planned to reuse all 6LoWPAN
    > as is, and more importantly, minimal enables to follow 802.15.4 and
    > 6LoWPAN as they evolves.

Do we?  Are we using ND for 6CO exchange?

Do we support ND-only nodes that don't speak RPL, 6top or minimal?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 09:21:00 -0500

Brian Haberman <[email-masked]> wrote:
    > BCP is not limited to network administration. They are also applicable
    > to implementers. RFCs 6881 and 7696 are examples of BCPs aimed at
    > implementers.

So I think these are poor examples, and actually demonstrates why minimal
should be standards track.

RFC7696:
             Guidelines for Cryptographic Algorithm Agility
            and Selecting Mandatory-to-Implement Algorithms

I read this as guidelines to people writing IETF protocol specifications.
For the people writing code or planning the implementation the protocol is
either algorithm agile or not.

RFC6881:
          Best Current Practice for Communications Services in
                      Support of Emergency Calling

is definitely more implementer focused, in that a product manager needs to
take this into account, and I can see "RFC6881 compliance" showing up in an
RFP.  I don't think our BCPs should show up be fundamental content in RFP.
(An person informed about both NAFTA/TPP/CETA and IETF process would conclude
our BCPs are not performance specifications under the agreement. Fortunately
for the IETF, there are few people who know both. I know it only as the
hammer we use to deal with vendor proprietary protocols in government procurement)

Minimal is definitely more like 6881 than 7696.

BUT, I think it (rfc6881) should have been published as standards track myself!

---

From: Brian Haberman <[email-masked]>
Date: Tue, 1 Dec 2015 12:52:55 -0500

Hi Michael,

> either algorithm agile or not.

I agree that my choice of wording and referencing 7696 wasn't the best.
In essence, I was pointing out that there are BCPs that are not directed
at operational aspects.

> BUT, I think it (rfc6881) should have been published as standards track myself!

Just so everyone is on the same page... BCPs are on equal footing with
standards track documents. The only real difference is that an ST
document can be advanced from PS to IS. And that was one of my
questions. Do people expect that this draft would have an advancement
path from PS to IS in the future?

Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Dec 2015 18:02:21 +0000

> Do we?  Are we using ND for 6CO exchange?
Not yet, and minimal does not specify that since it does not change it from the behavior of a 6LoWPAN node. The architecture sh/could.

> Do we support ND-only nodes that don't speak RPL, 6top or minimal?
The architecture does mention that as a goal, but we are missing the work at ROLL and 6lo.
This is exactly where minimal reuses whatever is in the environment for that, the environment being the current state of 6LoWPAN on normal 802.15.4.
Do you mean that we should be explicit in saying the a minimal node must support at least 6LoWPAN RFCs xxxx?

Pascal

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 13:29:03 -0500

> Not yet, and minimal does not specify that since it does not change it
    > from the behavior of a 6LoWPAN node. The architecture sh/could.

    > This is exactly where minimal reuses whatever is in the environment for
    > that, the environment being the current state of 6LoWPAN on normal
    > 802.15.4.

I'm saying that an IP-over-FOO(802.15.4e) should probably say these things.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 1 Dec 2015 13:46:27 -0500

> On Dec 1, 2015, at 8:03 AM 12/1/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph:
> 
> I understand that the 6TiSCH architecture, which describes as an informational the general topologies, the use of RPL and 6LoWPAN, and positions the 6BBR as well, is what you call b).

Not really what I was thinking...

I would think of (b) as a standalone "IPv6-over-foo" document, where "foo" is minimal 6TiSCH.  It would include all protocols and enough operational instruction and parameters to build an interoperable implementation from that one document.

(a) would be an addendum to a more general IPv6-over-6TiSCH document, giving only the diffs against the IPv6-over-6TiSCH document required for minimal operation.

> One intent was to back the minimal document with the architecture document so we would not have to place that informational background in the standard.

In that model (a), the minimal document needs to be written as an addendum to a full IPv6-over-6TiSCH document, not an architecture document.

> Minimal operating on 802.15.4, it works with the existing 6LoWPAN HD and ND, and does not need to change or parametrize them to operate as a NBMA mesh. A product that implements minimal will benefi…

Somewhere, there needs to be a specification to use 6lowpan and ND, and the specifics of how to use them.  I don't see any reference to those protocols in the existing draft-ietf-6tisch-minimal document nor do I see a specification to use any those protocols in any of the references cited in draft-ietf-6tisch-minimal.

6lowpan and ND are only examples.  There may be other protocols that need to be mentioned in the same way.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 1 Dec 2015 13:51:49 -0500

Following up on my previous e-mail, it's still not clear to me whether this document is intended to describe minimal operation of IEEE802.15.4 or minimal IPv6-over-IEEE802.15.4-TSCH.  The title is "Minimal 6TiSCH Configuration", but the first sentence of the abstract is "This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network."  "6TiSCH" is not used as the name of a protocol or specification anywhere else in the document.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Dec 2015 19:30:40 +0000

To which I agree to the point that foo is not TSCH but 802.15.4, and that minimal and 6TiSCH in general inherit that.
This is why we are working at 6lo to improve it in the more general space where it is actually defined... 

Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: mardi 1 décembre 2015 19:29
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 3 Dec 2015 08:27:35 +0100

Hi Tero, Brian,

I would like to understand better the difference from what you consider a
profile (and should be BCP) and what is a document in the standard track.
If I take for example IPv6 over BTLE,
https://tools.ietf.org/html/rfc7668

I can see it both as a profile of rfc4944 or as different specification, it
depends on my pre-conceived idea. (I think the same applies for the IPv6
over NFC under development).  As far as I understand this RFC does not
define any new field for a header but only how you use 6lowpan on top of
BTLE, that is how you set some MAC layer fields and how you use the MAC
layer information from an above perspective.

 You may argue that it defines how addresses are auto-configured which I
can argue this is a profile as it takes a set of already existing MAC layer
fields and prepends them with a prefix. This prefix is something already
known and defined in other RFCs. We can look into it in detail and I am
sure we can find arguments to say it is a profile.

Given that context can you please provide solid and objective arguments on
why the specification of a the profile of IPv6 on BTLE is an standard and
what we define in minimal (the 15.4e profile) it is not?

Does this depends on having sections saying for example that in minimal
address auto-configuration is done in the same way as IPv6 over 15.4 does
(rfc4944)?

thanks and sorry for asking, I am not able to see a clear boundary.

regards,
Xavi

---

From: Brian Haberman <[email-masked]>
Date: Mon, 7 Dec 2015 08:39:36 -0500

Hi Xavier,
     I think there are two things that separate 7668 from minimal. I
will point out that this is based on my reading of the documents, but I
want the WG to understand the differences in the tracks and make a
conscious decision on which is most applicable.

1. RFC 7668 is very clear on what it is defining. The intro contains an
explicit statement on that ("This document describes how IPv6 is
transported over Bluetooth LE..."). Minimal is far less definitive in
what it is defining ("One goal of this document is to define the
simplest set of rules for building a TSCH-compliant network...",
"...this minimal mode of operation MAY also be used during network
bootstrap...", and "...minimal configuration MAY be used as a fall-back
mode of operation..."). To me, that raises some questions. What exactly
is a TSCH-compliant network? Will networks fail if some devices do not
implement minimal for bootstrapping or fall-back since it is optional?

2. RFC 7668 falls in the standards track, in my opinion, due to the
strict guidance provided in sectins 3.2.3, 3.2.4, and 3.2.5. If those
rules are not followed, IPv6-over-BTLE won't work. Those types of
statements can be advanced along the standards track (PS -> IS). The
"advice" in minimal is far less declarative and appears to be advisory.

As I said in Yokohama, I can see minimal being re-worded as a standards
track document, but today it reads like a BCP or Informational document.

Regards,
Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2015 12:56:50 -0500

> track document, but today it reads like a BCP or Informational

I believe that this is a bug in the text, not in the intention.
A kind of shyness :-)

---

From: Pat Kinney <[email-masked]>
Date: Tue, 8 Dec 2015 09:48:13 -0600

Hi Xavi;

From my experience in SDOs and Alliances, the profile allows multiple vendors to create and configure devices that will interoperate with other devices and serve desired applications.  To do so, a profile defines which optional behaviors from a standard that are required (it may also declare which mandatory behaviors are required), and what configurations and parameter settings are to be used. 

For instance, a profile could state that the default settings for TSCH operation as stated in 802.15.4 will be used, the PHY will be the 2.4 GHz PHY using O-QPSK modulation over 15 channels, additionally security will be used with the parameters defined by the profile.

So, from my perspective, a profile is not a standard, rather it defines how a user will use “generic” standards (e.g. 802.15.4, 6tisch, 6LoWPAN) to assure interoperability in a way that serves the stated application(s).

Pat

On 3, Dec2015, at 1:27, Xavier Vilajosana <[email-masked]> wrote:

Hi Tero, Brian,

I would like to understand better the difference from what you consider a profile (and should be BCP) and what is a document in the standard track. If I take for example IPv6 over BTLE, 
https://tools.ietf.org/html/rfc7668 <https://tools.ietf.org/html/rfc7668>

I can see it both as a profile of rfc4944 or as different specification, it depends on my pre-conceived idea. (I think the same applies for the IPv6 over NFC under development).  As far as I understand this RFC does not define any new field for a header but only how you use 6lowpan on top of BTLE, that is how you set some MAC layer fields and how you use the MAC layer information from an above perspective.

 You may argue that it defines how addresses are auto-configured which I can argue this is a profile as it takes a set of already existing MAC layer fields and prepends them with a prefix. This prefix is something already known and defined in other RFCs. We can look into it in detail and I am sure we can find arguments to say it is a profile.

Given that context can you please provide solid and objective arguments on why the specification of a the profile of IPv6 on BTLE is an standard and what we define in minimal (the 15.4e profile) it is not? 

Does this depends on having sections saying for example that in minimal address auto-configuration is done in the same way as IPv6 over 15.4 does (rfc4944)?

regards,
Xavi

2015-12-01 13:21 GMT+01:00 Tero Kivinen <[email-masked] <mailto:[email-masked]>>:

Again profiling.

[email-masked] <mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Dec 2015 13:47:35 +0200

Xavier Vilajosana writes:
> Given that context can you please provide solid and objective arguments on why
> the specification of a the profile of IPv6 on BTLE is an standard and what we
> define in minimal (the 15.4e profile) it is not? 

Does minimal change anything in 802.15.4? I.e. is there something
there that is not already defined in 802.15.4 when suitable options of
the 802.15.4 is selected?

I.e. can someone take 802.15.4 and implement it, picking parameters
until he get the same parameters specified in the minimal and then
implement minimal without ever reading it.

My understanding is that yes, 802.15.4 complient implementation which
implements just what is already defined in the 802.15.4 can also be
complient with minimal, if it selects suitable options.

This would make it profile instead of new protocol.

When you start to implement things on top of that, for example the key
management or joining processes, then those parts are outside the
scope of 802.15.4 and you have to implement something not mentioned
there, then you are making new protocol.

On the other hand I do not think there is real difference between
those two, i.e. it does not matter whether it is profile or whether it
is new protocol for the IETF process point of view.

Currently the problem is that minimal is not clear what it tries to
be. The actual content of it is more like profile, i.e. it is just
telling which options of 802.15.4 to enable, but some of the text is
written in a way which would say it is new protocol as it copies
things from the 802.15.4.

It is not clear for me what should implementor do if he spots mismatch
between minimal and 802.15.4? Which one of them is authorative? If
this is profile, then 802.15.4 should be followed unless the mismatch
was explicitly spelled out. If this is new standard then this document
should be followed.

Also what does it mean when we have text saying for example "source
and destination address fields MUST be filled with an extended address
(64 bit)"? Does that mean that no minimal node can ever use any other
addressing formats?

I would assume it is supposing to mean that when using minimal profile
for the packets, we use those extended addresses, but anything that is
valid in the 802.15.4 network can also be used for other traffic in
the same network. I.e. this minimal just gives minimal
interoperability profile for the network so devices can use those
settings until they get something better.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2015 18:36:38 -0500

Tero Kivinen <[email-masked]> wrote:
    >> Given that context can you please provide solid and objective
    >> arguments on why the specification of a the profile of IPv6 on BTLE is
    >> an standard and what we define in minimal (the 15.4e profile) it is
    >> not? 

    > Does minimal change anything in 802.15.4? I.e. is there something there
    > that is not already defined in 802.15.4 when suitable options of the
    > 802.15.4 is selected?

    > implement minimal without ever reading it.

(I think you write 802.15.4 here rather than 15.4e, because as of now, the
documents are one)

    > This would make it profile instead of new protocol.

I think that something is a "protocol" (and therefore a "new" protocol), if
there is some interaction in which decisions occur.  A profile has no
decisions, because they are all setup in advance in the document.

Do you agree?
I'm asking because it would be good to agree on what is a "new protocol",
before we decide if minimal is new or not.

    > management or joining processes, then those parts are outside the scope
    > of 802.15.4 and you have to implement something not mentioned there,
    > then you are making new protocol.

    > On the other hand I do not think there is real difference between those
    > two, i.e. it does not matter whether it is profile or whether it is new
    > protocol for the IETF process point of view.

Would a profile = BCP?