Hello Michael:
Today, undated and without the 'e', IEEE802.15.4 means 2011 plus all the
amendments.
Robert has summarized it all in the attached mails for us.
Cheers,
Pascal
> -----Original Message-----
> From: 6tisch [mailto:[email protected]] On Behalf Of Michael Richardson
> Sent: jeudi 30 avril 2015 06:24
> To: [email protected]
> Subject: Re: [6tisch] Removing the 'e' in the charter
>
>
> Pascal Thubert (pthubert) <[email protected]> wrote:
> > At the interim last Friday we found that we should not mix the
> > question on the references in the draft and that of the ‘e’ in the
> > charter.
>
> > For the specific case of the ‘e’, we discussed that the group will not
> > stop brutally at the end of 2015 and that we really work on TSCH, so
> > we could remove the ‘e’.
>
> > This is a call for consensus. The proposal on the table is effectively
> > to remove the ‘e’; if you disagree please let us know now.
>
> I still do not understand IEEE referencing rules.
>
> I found one of Pascal's comments interesting. If I understood, he said:
> * If we reference IEEE document without a year (or I guess, letter), and
> IEEE
> breaks something in a future that we depend upon, then we would have a
> basis for complaint.
> * If we reference IEEE document with a year, then we have no basis for a
> complaint, as they aren't changing/breaking the old spec.
>
> But, I'm unclear what it means to reference "802.15.4" today, when
> 802.15.4-2015 is not yet published (Auguest 2015, said Pat).
> I therefore think it appropriate to drop the "e" only when the -2015 is out,
> so
> let's do that in November. At which point, my question about -year vs not
> year
> might have a different answer.
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works -=
> IPv6 IoT consulting =-
>
>
--- Begin Message ---
When a new revision is approved, in IEEE terminology, the old standard is
superseded, including any approved amendments and corrigenda. It is also
possible to withdraw an IEEE standard (less common. Superseded and withdrawn
standards remain available.
In IEEE, there is a rule, that once approved an amendment or corrigenda to a
standard becomes part of that standard. So, today, a reference to IEEE Std
802.3-2012 technically also includes IEEE Std 802.3bk-2013, IEEE Std
802.3bj-2014 and IEEE Std 802.3bm-2015 (as indicated by Ralph’s description of
802.15.4 being a collection) . 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.
The current revision of IEEE Std 802.11-2012 includes five amendments. The
cover page of revision drafts and the published revision both include a list of
the included documents (previous revision, amendments and corrigenda).
IEEE Std 802.15.3-2003 only has two approved amendments but because of IEEE
rules, it will have to be revised so that two current amendment projects can be
approved. (After three years, an IEEE standard must be revised if there are
three or more approved amendments before an additional amendment can be
approved, unless an extension to the rule is granted.) This results in
frequent revisions to active 802 standards, and consequently a motivation to
use undated references when possible.
As Pat noted, when referencing a specific section of a document, the dated
version indicates where to find the actual text considered when writing the
RFC. In that case, it would be appropriate to directly reference an amendment
even though the amendment is technically part of the base standard (a kindness
to readers of the RFC).
Pascal, because of the inclusion of amendments and corrigenda in the base, the
note might have to be more detailed and include listing the approved amendments
also considered by the RFC. Such a note might be simply, "At the time of
publication of this RFC, IEEE Std 802.15.4 consisted of IEEE Std 802.15.4-2011,
IEEE ,,,” (there are currently seven approved amendments). This though creates
a possible accuracy problem as there could be a race between doing the
technical work on the RFC and approval of an amendment. An alternative would
be, In development of this RFC, IEEE Std 802.99 documents considered included
IEEE Std 802.99-2016 and P802.99/D8. (The later allowing consideration of a
draft that is not expected to change in a substantive way.)
—Bob
On Apr 1, 2015, at 10:40 AM, Ralph Droms <[email protected]> wrote:
>
>> On Apr 1, 2015, at 1:32 PM 4/1/15, Pascal Thubert (pthubert)
>> <[email protected]> wrote:
>>
>> Hello Heather:
>>
>> We can expect that the text has some dependencies on the target SDO. Because
>> we do not do things the same way.
>>
>> We, at the IETF, deprecate and RFC by a new one; it is unclear to me what
>> becomes of RFCb that references RFCa after RFCa is deprecated and until RFC
>> is deprecated.
>>
>> The IEEE does things differently. E.g. IEEE802.15.4 is a collection of the
>> LATEST version of the standard and the sum of all amendments till now. This
>> implies a different handling of the reference.
>> If another SDO does things in yet another fashion, we will have to adapt as
>> well. Tom (added to the discussion) and the IEC did a great job at dealing
>> with that problem, and we c(sh)ould take inspiration from them.
>
> Don't the various versions of an IEEE standards document have appended
> versioning information; e.g.:
>
> IEEE STANDARD 802.15.4-2011 - IEEE Standard for Local and metropolitan area
> networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
>
> - Ralph
>
>>
>> We could for instance request to add a note of applicability to the standard
>> reference for all normative references outside the IETF, as suggested in RFC
>> 4897 for some IETF references.
>>
>> For IEEE, the note could be, like, "this RFC is design to apply on the
>> version of <IEEE standard blah without a date, e.g. IEEE802.15.4> that is
>> current at the time of publication of this RFC, and that it is expected but
>> not guaranteed that this RFC applies to <IEEE standard blah without a date>
>> versions published after the publication of this RFC. The earliest version
>> of <IEEE standard blah without a date> that is supported is from <date,
>> amendment>.".
>>
>> What do you think?
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: ieee-ietf-coord [mailto:[email protected]] On Behalf Of
>>> Heather Flanagan (RFC Series Editor)
>>> Sent: mercredi 1 avril 2015 16:26
>>> To: [email protected]
>>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
>>>
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 4/1/15 7:10 AM, Barry Leiba wrote:
>>>> Hi, Pascal. Thanks for digging into this.
>>>>
>>>>> All in all, do we have a best practice for IEEE references? If not,
>>> should
>>>>> we write one?
>>>>
>>>> I think that would be a fine idea. I think you should talk it over
>>>> with Heather (RFC Series Editor) before embarking on that, to make
>>>> sure it meshes with the RFC Editor view of handling references. And
>>>> it would be nice if the advice could generally apply to references to
>>>> documents by other SDOs, rather than just to IEEE.
>>>
>>> And in fact, we do have some guidance on referencing other SDOs in the RFC
>>> Style Guide (RFC 7322, Section 4.8.66). But that's not specific to IEEE,
>>> and
>>> doesn't get into the detail I think you're looking for.
>>>
>>>>
>>>>
>>>>> - The general expectation is that work at the IETF that depends on an
>>> IEEE
>>>>> standard stays valid when a newer version of that IEEE standard that
>>>>> gets published. This is certainly the case for the RFCs listed above.
>>>>>
>>>>> - My understanding is that the IEEE expects an RFC to reference the
>>>>> IEEE standard without the year-version (e.g. 802.15.4 as opposed to
>>>>> 802.15.4-2006) when that is the case, so as to implicitly include new
>>>>> upcoming versions.
>>>>
>>>> As a general case, that's definitely true.
>>>>
>>>> And I'm sure that when there are clear version-dependencies, that's
>>>> well known and the authors will handle that.
>>>>
>>>> Where it becomes dicey is when (as we should when we reference a
>>>> lengthy specification) we cite a specific section in order to help the
>>>> reader find what we're referencing... and then, while the substance
>>>> doesn't change in a future version, the section number does. I think
>>>> that can be handled by coding the section reference carefully ("see
>>>> Section 6.1 in the 2006 version", or some such), but it's something
>>>> that probably deserves mention in any advice on how to do the
>>>> references.
>>>>
>>>
>>> I'd be happy to get into more detail with anyone interested in spending some
>>> time on it. I'd prefer that it be more broadly applicable than just the
>>> IEEE.
>>>
>>> - -Heather
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iQEcBAEBCAAGBQJVG//4AAoJEER/xjINbZoGZ3oH/iUPtgj+9xtD2h2xhjGIOTNy
>>> xpz3dPX2ZIHTYOrsUde1CmxzinPMBCYyGibppbae0yP5kb3wDoBd9IePoQGfNNLe
>>> gGSROmURw4+cgzk0qTDApiXDz3PbsJ79LbEAZq2KCQFTRF7/tRfMvWMUey2lTdb
>>> G
>>> JbCyEmnVNjQYaJ74s4XtK3PDw5amX5nETaAipTyDsraUMteJYawcRK9OQFZ8KUby
>>> vZu+IMgDOTkSss0sw9e9I63ZS91170C80BCrpHmCOpDESzYKRaNdWtEZVdIE7Tyb
>>> sCSYlpQdJN+6yMWwscULfilTrUOZ9bSOI489NYX1z9oXcc0peYwrAJy4OVqHOA4=
>>> =53Fo
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> <Mail Attachment.eml><Mail Attachment.eml><Mail
>> Attachment.eml>_______________________________________________
>> ieee-ietf-coord mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>
> _______________________________________________
> ieee-ietf-coord mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
--- End Message ---
--- Begin Message ---
Pascal:
I’m not the best source for accuracy of 802.15 information, but from my files,
the history of 802.15.4 is:
IEEE Std 802.15.4-2003
IEEE Std 802.15.4-2006
IEEE Std 802.15.4a-2007
IEEE Std 802.15.4c-2009
IEEE Std 802.15.4d-2009
IEEE Std 802.15.4-2011
IEEE Std 802.15.4e-2012
IEEE Std 802.15.4f-2012
IEEE Std 802.15.4g-2012
IEEE Std 802.15.4j-2013
IEEE Std 802.15.4k-2013
IEEE Std 802.15.4m-2014
IEEE Std 802.15.4p-2014
Current active PARs
P802.15.4 (revision)
P802.15.4-2011/Cor 1
P802.15.4n
P802.15.4q
P802.15.4r
P802.15.4s
(Why they have a corrigendum and revision project both open today I can’t
explain. They should be able to do the corrigendum corrections in the
revision, and reports I looked at indicate that might be what is happening.
The revision received conditional approval for Sponsor Ballot in March,
typically meaning that a new revision will be completed this year. The active
amendment projects will then become amendments to IEEE Std 802.15.4-20xx
(presumably 2015).)
More information below.
—Bob
On Apr 2, 2015, at 9:28 AM, Pascal Thubert (pthubert) <[email protected]>
wrote:
> This is incredibly useful Robert!
>
> Thanks for every single word of it; it's all very clear, but yields
> additional need for clarification.
>
> - RFC 4944 has the following NORMATIVE reference:
> [ieee802.15.4] IEEE Computer Society, "IEEE Std.
> 802.15.4-2003", October 2003.
> Does it mean that the 6LoWPAN is currently not defined on the 2006 and the
> 2011 versions of 802.15.4?
<RMG> Seems like the reference should probably be without year. Best to check
with an 802.15 expert on any potential problems. With Ethernet, we don’t care
what runs above the MAC sublayer. I think 802.15 though has done some
specifications higher up the stack. One minor problem I didn’t mention with
undated references is that document titles can change with a revision. I note
that IEEE Std 802.15.4 has abbreviated its title between 2003 and 2011. The
title today is: IEEE Standard for Local and metropolitan area networks—Part
15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). Approval of all
IEEE standards is actually by the IEEE Standards Association for all IEEE
Standards (IEEE Standards Association, IEEE Computer Society and Sponsored by
the LAN/MAN Standards Committee is just IEEE organizational stuff.) The
copyright for any IEEE standard is owned by The Institute of Electrical and
Electronics Engineers, Inc.
One thing IEEE typically does in include a paragraph before the list of
normative references encouraging consideration of the latest version of the
references (as well as explaining that undated references indicate the latest
revision should be used. So, by my training, the 2003 dated reference only
indicates what was the case when the RFC was written. It doesn’t mean that
6LoWPAN can’t be used with the current revision.
>
> - RFC 6282 points on the 2006 version, but as INFORMATIVE:
> [IEEE802.15.4] IEEE Computer Society, "IEEE Std.
> 802.15.4-2006", October 2006.
> Does the INFORMATIVE change anything to the applicability of the RFC to
> various levels of the MAC/PHY?
<RMG> IETF interpretation of informative and normative may be different than
the meaning of the terms in IEEE standards. Informative content is helpful but
not required to implement the standard. Ethernet doesn’t care if it has IPv4,
IPv6 or something else running above it, so for those higher transport
protocols, an informative reference is appropriate. A management RFC though
might appropriately use a normative reference to IEEE Std 802.3.1, Ethernet
MIBs. Again though, the dated reference does not necessarily preclude use of
an RFC with newer versions of the IEEE standard.
>
> - We are discussing pointing to our charter and documents to " IEEE Std.
> 802.15.4" with no date. Today, the base 802.15.4 spec is 2011. Would that
> reference it mean that 2006 and 2003 are implicitly supported not supported?
<RMG> Here, I’ll have to go to Ethernet again because of my lack of familiarity
with Wireless PAN.
1. The original Ethernet standard was dated 1985. It specified 10BASE5. A
few revisions ago, we deprecated 10BASE-5 with text that remains that 10BASE-5
is not recommended for new installations. Since 10BASE-5 is still in the
current revision project, it will continue to be a conformant speed and media
option for Ethernet.
2. Link Aggregation though is a different case, the specifications for this
were moved to IEEE Std 802.1AX, so a undated reference to 802.3 would not get
you Link Aggregation specifications. All you find in Clause 43 now is:
"NOTE—The Link Aggregation specification was moved to IEEE Std 802.1AX(TM)-2008
during the IEEE Std 802.3-2008 revision.” So an undated reference in a 2007
RFC would not include Link Aggregation, but at least with Std 802.3, an
implementer can find the specifications.
3. You may be familiar with Cat 5e cables for Ethernet. In 802.3, we
typically use ISO/IEC cabling standard references rather than the TIA
specifications for Cat x cables. So, you will find 100BASE-TX 802.3
specifications now reference the 1995 standard for Class D (essentially the
same as TIA Cat 5), because the subsequent revision redefined Class D to be
equivalent to Cat 5e (what is required for 1000BASE-T). (We didn’t want to
make a Cat 5 cabling installation non-conformant to the current standard just
because of the change in the ISO/IEC 11801 standard for Class D. Not all
standards groups will be as careful in preserving conformance of legacy
equipment.)
One risk then with an undated reference is if the referenced standard deletes
something you are using (e.g., the 802.3 Link Aggregation example); and an old
undated reference is no longer valid for the intended purpose of the reference.
There is a similar risk for changes in specification (e.g. the 802.3 Class D
example).
>
> - Same question if we added 2011; I understand from the clarification in your
> mail that it would mean that the amendment is included; but what about 2003
> and 2006?
<RMG> You would have to ask an 802.15 expert if anything of relevance was
deleted during the revisions. Typically we just add and correct content over
the years, but as noted above, not always. The 801.15.4-2003 initial standard
was superseded by the 2006 revision, and the 2006 revision superseded by the
2011 revision. The 2011 revision will similarly be superseded by the current
revision project when it is approved.
>
> - As it goes, the TSCH operation that we need came in with the amendment
> 802.15.4e, meaning that -2011 did not incorporate it prior to sometime in
> 2012 when the amendment was published. If the answer to the one of questions
> above is that 2006 is implicitly supported, then we need to add something in
> the node that says that 802.15.4 is OK starting from that date in 2012 or
> from that amendment. Would you have a suggestion to word that correctly?
<RMG> Making a recommendation here is dangerous because of my ignorance about
both 802.15.4 and TSCH. If referencing 2011, I would probably add an
informative note that the RFC relies on the capabilities added to IEEE Std
802.15.4-2011 by IEEE Std 802.15.4e-2012. (Few of the RFC readers would be
aware of the level of detail we have been discussing and the subtlety that
amendments become part of the base standard when approved, so a note would make
the document user friendly. Because you might be in a race with the current
802.15.4 revision, I personally would even do that for an undated reference.)
>
> Thanks again!!!
>
> Pascal
>
>
>> -----Original Message-----
>> From: ROBERT GROW [mailto:[email protected]]
>> Sent: mercredi 1 avril 2015 22:53
>> To: Ralph Droms
>> Cc: Pascal Thubert (pthubert); Tom Phinney; Heather Flanagan (RFC Series
>> Editor); [email protected]
>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in IETF RFCs
>>
>> When a new revision is approved, in IEEE terminology, the old standard is
>> superseded, including any approved amendments and corrigenda. It is also
>> possible to withdraw an IEEE standard (less common. Superseded and
>> withdrawn standards remain available.
>>
>> In IEEE, there is a rule, that once approved an amendment or corrigenda to a
>> standard becomes part of that standard. So, today, a reference to IEEE Std
>> 802.3-2012 technically also includes IEEE Std 802.3bk-2013, IEEE Std 802.3bj-
>> 2014 and IEEE Std 802.3bm-2015 (as indicated by Ralph's description of
>> 802.15.4
>> being a collection) . 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.
>>
>> The current revision of IEEE Std 802.11-2012 includes five amendments. The
>> cover page of revision drafts and the published revision both include a list
>> of the
>> included documents (previous revision, amendments and corrigenda).
>>
>> IEEE Std 802.15.3-2003 only has two approved amendments but because of IEEE
>> rules, it will have to be revised so that two current amendment projects can
>> be
>> approved. (After three years, an IEEE standard must be revised if there are
>> three
>> or more approved amendments before an additional amendment can be
>> approved, unless an extension to the rule is granted.) This results in
>> frequent
>> revisions to active 802 standards, and consequently a motivation to use
>> undated
>> references when possible.
>>
>> As Pat noted, when referencing a specific section of a document, the dated
>> version indicates where to find the actual text considered when writing the
>> RFC.
>> In that case, it would be appropriate to directly reference an amendment even
>> though the amendment is technically part of the base standard (a kindness to
>> readers of the RFC).
>>
>> Pascal, because of the inclusion of amendments and corrigenda in the base,
>> the
>> note might have to be more detailed and include listing the approved
>> amendments also considered by the RFC. Such a note might be simply, "At the
>> time of publication of this RFC, IEEE Std 802.15.4 consisted of IEEE Std
>> 802.15.4-
>> 2011, IEEE ,,," (there are currently seven approved amendments). This though
>> creates a possible accuracy problem as there could be a race between doing
>> the
>> technical work on the RFC and approval of an amendment. An alternative would
>> be, In development of this RFC, IEEE Std 802.99 documents considered included
>> IEEE Std 802.99-2016 and P802.99/D8. (The later allowing consideration of a
>> draft that is not expected to change in a substantive way.)
>>
>> -Bob
>>
>> On Apr 1, 2015, at 10:40 AM, Ralph Droms <[email protected]> wrote:
>>
>>>
>>>> On Apr 1, 2015, at 1:32 PM 4/1/15, Pascal Thubert (pthubert)
>> <[email protected]> wrote:
>>>>
>>>> Hello Heather:
>>>>
>>>> We can expect that the text has some dependencies on the target SDO.
>> Because we do not do things the same way.
>>>>
>>>> We, at the IETF, deprecate and RFC by a new one; it is unclear to me what
>> becomes of RFCb that references RFCa after RFCa is deprecated and until RFC
>> is
>> deprecated.
>>>>
>>>> The IEEE does things differently. E.g. IEEE802.15.4 is a collection of the
>> LATEST version of the standard and the sum of all amendments till now. This
>> implies a different handling of the reference.
>>>> If another SDO does things in yet another fashion, we will have to adapt as
>> well. Tom (added to the discussion) and the IEC did a great job at dealing
>> with
>> that problem, and we c(sh)ould take inspiration from them.
>>>
>>> Don't the various versions of an IEEE standards document have appended
>> versioning information; e.g.:
>>>
>>> IEEE STANDARD 802.15.4-2011 - IEEE Standard for Local and metropolitan
>>> area networks--Part 15.4: Low-Rate Wireless Personal Area Networks
>>> (LR-WPANs)
>>>
>>> - Ralph
>>>
>>>>
>>>> We could for instance request to add a note of applicability to the
>>>> standard
>> reference for all normative references outside the IETF, as suggested in RFC
>> 4897 for some IETF references.
>>>>
>>>> For IEEE, the note could be, like, "this RFC is design to apply on the
>>>> version of
>> <IEEE standard blah without a date, e.g. IEEE802.15.4> that is current at
>> the
>> time of publication of this RFC, and that it is expected but not guaranteed
>> that
>> this RFC applies to <IEEE standard blah without a date> versions published
>> after
>> the publication of this RFC. The earliest version of <IEEE standard blah
>> without a
>> date> that is supported is from <date, amendment>.".
>>>>
>>>> What do you think?
>>>>
>>>> Pascal
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ieee-ietf-coord [mailto:[email protected]] On
>>>>> Behalf Of Heather Flanagan (RFC Series Editor)
>>>>> Sent: mercredi 1 avril 2015 16:26
>>>>> To: [email protected]
>>>>> Subject: Re: [ieee-ietf-coord] On references to IEEE standards in
>>>>> IETF RFCs
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> On 4/1/15 7:10 AM, Barry Leiba wrote:
>>>>>> Hi, Pascal. Thanks for digging into this.
>>>>>>
>>>>>>> All in all, do we have a best practice for IEEE references? If
>>>>>>> not,
>>>>> should
>>>>>>> we write one?
>>>>>>
>>>>>> I think that would be a fine idea. I think you should talk it over
>>>>>> with Heather (RFC Series Editor) before embarking on that, to make
>>>>>> sure it meshes with the RFC Editor view of handling references.
>>>>>> And it would be nice if the advice could generally apply to
>>>>>> references to documents by other SDOs, rather than just to IEEE.
>>>>>
>>>>> And in fact, we do have some guidance on referencing other SDOs in
>>>>> the RFC Style Guide (RFC 7322, Section 4.8.66). But that's not
>>>>> specific to IEEE, and doesn't get into the detail I think you're looking
>>>>> for.
>>>>>
>>>>>>
>>>>>>
>>>>>>> - The general expectation is that work at the IETF that depends on
>>>>>>> an
>>>>> IEEE
>>>>>>> standard stays valid when a newer version of that IEEE standard
>>>>>>> that gets published. This is certainly the case for the RFCs listed
>>>>>>> above.
>>>>>>>
>>>>>>> - My understanding is that the IEEE expects an RFC to reference
>>>>>>> the IEEE standard without the year-version (e.g. 802.15.4 as
>>>>>>> opposed to
>>>>>>> 802.15.4-2006) when that is the case, so as to implicitly include
>>>>>>> new upcoming versions.
>>>>>>
>>>>>> As a general case, that's definitely true.
>>>>>>
>>>>>> And I'm sure that when there are clear version-dependencies, that's
>>>>>> well known and the authors will handle that.
>>>>>>
>>>>>> Where it becomes dicey is when (as we should when we reference a
>>>>>> lengthy specification) we cite a specific section in order to help
>>>>>> the reader find what we're referencing... and then, while the
>>>>>> substance doesn't change in a future version, the section number
>>>>>> does. I think that can be handled by coding the section reference
>>>>>> carefully ("see Section 6.1 in the 2006 version", or some such),
>>>>>> but it's something that probably deserves mention in any advice on
>>>>>> how to do the references.
>>>>>>
>>>>>
>>>>> I'd be happy to get into more detail with anyone interested in
>>>>> spending some time on it. I'd prefer that it be more broadly applicable
>>>>> than
>> just the IEEE.
>>>>>
>>>>> - -Heather
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG/MacGPG2 v2
>>>>> Comment: GPGTools - http://gpgtools.org
>>>>>
>>>>>
>> iQEcBAEBCAAGBQJVG//4AAoJEER/xjINbZoGZ3oH/iUPtgj+9xtD2h2xhjGIOTNy
>>>>>
>> xpz3dPX2ZIHTYOrsUde1CmxzinPMBCYyGibppbae0yP5kb3wDoBd9IePoQGfNNLe
>>>>>
>> gGSROmURw4+cgzk0qTDApiXDz3PbsJ79LbEAZq2KCQFTRF7/tRfMvWMUey2lTdb
>>>>> G
>>>>>
>> JbCyEmnVNjQYaJ74s4XtK3PDw5amX5nETaAipTyDsraUMteJYawcRK9OQFZ8KUby
>>>>>
>> vZu+IMgDOTkSss0sw9e9I63ZS91170C80BCrpHmCOpDESzYKRaNdWtEZVdIE7Tyb
>>>>>
>> sCSYlpQdJN+6yMWwscULfilTrUOZ9bSOI489NYX1z9oXcc0peYwrAJy4OVqHOA4=
>>>>> =53Fo
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ieee-ietf-coord mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>> <Mail Attachment.eml><Mail Attachment.eml><Mail
>>>> Attachment.eml>_______________________________________________
>>>> ieee-ietf-coord mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>>>
>>> _______________________________________________
>>> ieee-ietf-coord mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>
> _______________________________________________
> ieee-ietf-coord mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
--- End Message ---
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
