Kris,
I certainly see you point and agree with your basic concern of
interoperability. We can have 4e in the minimal draft to get things
started.
Ideally, I would have liked the top down approach by defining abstract
link as seen by the network layer, its requirements and give 4e as one
of the suitable candidates that meets these. If the minimal draft
conveys this spirit, we all can breathe freely !
When I mentioned about the abstract MAC layer over basic 15.4, the idea
is to convey that what the network layer cares about is the links and
their states. This requirement automatically translates to some kind of
beaconing and the link information they should carry. Whether beaconing
happens over ICMP or UDP, or ..., is a different matter. This is what I
would have done if I were to have proposed that fictional draft I was
talking about in pre-4e era. RPL, RSVP, OSPF and many more have ways of
providing means of joining the network, learning about links and
maintaining them without being tied to a particular link protocol.
It is very relieving that we are thinking about the future before it is
too late to rectify.
Thanks
Anand
On 05/01/2015 11:12 PM, Kris Pister wrote:
+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]> 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, 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, 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, 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, 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, and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
