+1 on removing e from the charter.
+1 on removing e from any higher layer documents
This statement is not completely correct:
> an Internet draft that defines an abstract MAC layer, much before
> IEEE came up with 4e. What would have happened in that
> scenario ? 6tisch would have been defined on top of that layer. Right ?
If we had that abstract MAC layer, then things like PCE and OTF control of
resources would be defined on the abstraction, and perhaps YANG models
and CoAP resources, etc. I think that we can still do that without the e,
which is good.
But the original goal of 6TiSCH was to create a document to define the
interface between the very flexible 4e/TSCH layer, and all of the
very useful abstractions of the IETF. If there were an existing abstraction
of TSCH MAC behavior, that would make life easier, but we would still
need at least one simple document to say
* this is how you beacon and join
* this is the minimal MAC capability that you MUST implement
Without that document, there are myriad incompatible ways that smart
well-intentioned people can properly implement these things. That's what
minimal is meant to do. It needs to be specific to allow interop today, and
five years from today, which means it can't be subject to a shifting spec,
and must refer to 4e (or -2015 if that comes out before we go to IESG
review).
Everything above it should be agnostic, and can drop the e and the -20xx .
ksjp
On 5/1/2015 10:12 AM, S.V.R.Anand wrote:
Absolutely :)
On Friday 01 May 2015 10:38 PM, Pascal Thubert (pthubert) wrote:
+1
This abstraction would work on many PHYs, including .11ac;
We have to start small but the vision can be much larger...
Cheers,
Pascal
Le 1 mai 2015 à 19:02, S.V.R.Anand <[email protected]
<mailto:[email protected]>> a écrit :
Hi,
I agree with the proposal that 'e' needs to be removed. I am of the
view that
removing 'e' is good for the charter as it gives flexibility for IETF to
propose future drafts without being tied to a particular
specification as in
the case of IEEE. Here is my take on this. Let us assume
hypothetically that
the idea of TDMA based channel hopping over basic 15.4 had occurred
to one of
the Internet experts and proposed an Internet draft that defines an
abstract
MAC layer, much before IEEE came up with 4e. What would have
happened in that
scenario ? 6tisch would have been defined on top of that layer. Right ?
Just that it did not happen.
What I mentioned above could have easily happened, as after all,
time based
link sharing on top of an existing physical MAC is not new to the
Internet
world at all. Loosely speaking rate limiters, packet shapers, MPLS,
VLANs, and
friends are trying to create virtual/abstract MACs on top of the
physical MACs,
ala IEEE 802.3.
Essentially, 4e is just one way of creating MAC access abstraction.
IETF should
have the flexibility of defining other interesting link sharing
mechanisms, not
unduely limited by what IEEE defines. 4e can be a subset.
Anand
On Friday 01 May 2015 03:19 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Qin:
>
>
>
> This is why Minimal and probably 6top will need to keep a dated
reference. The price to pay will be to publish an update is the
conversion is non obvious to future versions on the IEEE standard&
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> From: 6tisch [mailto:[email protected]] On Behalf Of Qin Wang
> Sent: jeudi 30 avril 2015 13:35
> To: Pat Kinney; Pascal Thubert (pthubert)
> Cc: Michael Richardson; [email protected]; ROBERT GROW ([email protected])
> Subject: Re: [6tisch] Removing the 'e' in the charter
>
>
>
> Hi all,
>
>
>
> I understand that reference IEEE 802.15.4 includes IEEE802.15.4e
by definition. But I have a problem in writing 6TiSCH draft if we
remove "e" in reference.
>
>
>
> Here is an example. "A 10ms time slot length is the default value
defined by [IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e]
defines a default macTimeslotTemplate,...." is in the section 3.4 of
minimal draft. Then, the question is how to point the exact place if
we use IEEE 802.15.4 as reference.
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
>
>
> On Friday, May 1, 2015 12:55 AM, Pat Kinney
<[email protected]> wrote:
>
>
>
> An amendment references (is based upon) the latest revision when
it was approved, hence 802.15.4e is based upon (i.e. it references)
802.15.4-2011.
>
> Pat
> Pat Kinney
> Kinney Consulting LLC
> IEEE 802.15 WG vice chair, TG chair
> ISA100.11a WG chair
> O: +1.847.960.3715
> [email protected]
>
>
>
>
>
>
> On 30, Apr2015, at 10:37, Pascal Thubert (pthubert)
<[email protected]> wrote:
>
> Hello Michael
>
> For All I know 4e TSCH is only defined on 2011. There are known
similar technologies running over 2006 but they are not 4e...
>
> The undated reference in an RFC to an IEEE spec applies to the
present state at the date of the RFC and to all future versions
unless the RFC is revised.
>
> This proved useful for Ethernet; too much maybe since we were
fooled into extending IP over Ethernet to Wi-Fi...
>
> Cheers,
>
> Pascal
>
> > Le 30 avr. 2015 à 07:50, Michael Richardson
<[email protected]> a écrit :
> >
> >
> > Pascal Thubert (pthubert) <[email protected]> wrote:
> >> Today, undated and without the 'e', IEEE802.15.4 means 2011
plus all
> >> the amendments.
> >
> > Given that we can't run on 802.15.4-2011, this is why I'm
concerned about
> > referencing "802.15.4".
> >
> >> So, a reference to IEEE Std 802.3 (without year) today is
identical to the
> >> 2012 dated reference, but when the current revision is approved
(expected
> >> this year), a reference to the 2012 revision would not include the
> >> maintenance changes included in the current revision, nor any
of the
> >> amendments likely to be approved soon after the revision is
approved.
> >
> > How does an outsider know when the reference was made? Is it by
the date
> > of the document making the reference?
> >
> > If the IETF writes a document in 2014, but it doesn't get
published in Jan. 2015,
> > what IEEE document would "802.15.4" reference?
> >
> > Robert suggests text like:
> >
> >> In development of this RFC, IEEE Std 802.99 documents
considered included
> >> IEEE Std 802.99-2016 and P802.99/D8.
> >
> > and so if we can do this, then I'm happy.
> >
> >
> >
> >
> > --
> > Michael Richardson <[email protected]>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
