10102014 Webex IPv 6 over the TSCH mode
10/10/2014 Webex IPv 6 over the TSCH mode of IEEE 802. 15. 4 e Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: http: //etherpad. tools. ietf. org: 9000/p/6 tisch
Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: • By participating with the IETF, you agree to follow IETF processes. • If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. • You understand that meetings might be recorded, broadcast, and publicly archived. For further information, talk to a chair, ask an Area Director, or review the following: • BCP 9 (on the Internet Standards Process) • BCP 25 (on the Working Group processes) • BCP 78 (on the IETF Trust) • BCP 79 (on Intellectual Property Rights in the IETF) 2
Reminder: Minutes are taken * This meeting is recorded ** Presence is logged *** * Scribe; please contribute online to the minutes at http: //etherpad. tools. ietf. org: 9000/p/6 tisch? use. Monospace. Font=true ** Recordings and Minutes are public and may be subject to discovery in the event of litigation. *** From the Webex login 3
Agenda • Administrivia – – [3 min] Approval agenda Approval minutes last call update format of calls IETF 91 6 Ti. SCH WG meeting • Wrapping up draft-ietf-6 tisch-tsch • YANG model [15 min] – updates to format – is interface complete? • Closing discussion on use of flow labels • RFC 7322: RFC Style Guide • AOB [15 min] [2 min] – reminder next calls 4
Administrivia
Admin is trivia • Approval Agenda • Approval minutes last call 6
Quick News on Interop tests 7
Formal of calls • https: //www. ietf. org/iesg/statement/interimmeetings. html • Announce officially on ietf-announce 2 weeks before (or by groups) • Send agenda 1 week before on 6 Ti. SCH ML • Minutes to proceedings@ietf. org at most 10 days after
IETF 91 • Asked for 90 min session, late in the week, early in the (Hawaii’an) morning • Remote participation possible
IETF 91 Important Dates • • • • • 2014 -08 -18 (Week of): IETF Online Registration opens. 2014 -08 -11 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. 2014 -09 -26 (Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23: 59. To request a Working Group session, use the IETF Meeting Session Request Tool. 2014 -09 -26 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23: 59. To request a BOF, please see instructions on Requesting a BOF. 2014 -10 -03 (Friday): Cut-off date for Area Directors to approve BOFs at UTC 23: 59. 2014 -10 -10 (Friday): Preliminary agenda published for comment. 2014 -10 -13 (Monday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23: 59. 2014 -10 -17 (Friday): Final agenda to be published. 2014 -10 -27 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23: 59, upload using IETF ID Submission Tool. 2014 -10 -27 (Monday): Draft Working Group agendas due by UTC 23: 59, upload using IETF Meeting Materials Management Tool. 2014 -10 -31 (Friday): Early Bird registration and payment cut-off at UTC 23: 59. 2014 -11 -03 (Monday): Revised Working Group agendas due by UTC 23: 59, upload using IETF Meeting Materials Management Tool. 2014 -11 -03 (Monday): Registration cancellation cut-off at UTC 23: 59. 2014 -11 -07 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17: 00 local meeting time. 2014 -11 -09 - 2014 -11 -14: 91 st IETF Meeting in Honolulu, HI, USA. 2014 -12 -05 (Friday): Proceedings submission cutoff date by UTC 23: 59, upload using IETF Meeting Materials Management Tool. 2014 -12 -26 (Friday): Proceedings submission corrections cutoff date by UTC 23: 59, upload using IETF Meeting Materials Management Tool.
Wrapping up draft-ietf-6 tisch-tsch
Recent Reviews • Ines: Issues 22, 24, 25 and 26 – why EB are sent on all frequencies – use of join priority – use of MLME-TSCH-MODE. request – replace generic terms "length“ • Pascal: Issue 27 – Compound issue, mostly misc. editorials • Better a few more to go WGLC 12
Goal • Propose rewording • Rough consensus on call, confirm on ML • Republish Running version: https: //bitbucket. org/6 tisch/draft-ietf-6 tischtsch/
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/22 summary: clarify why EB are sent on all frequencies OLD: Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1 -byte join priority. Because of the channel hopping nature of TSCH, these EB frames are sent on all frequencies. NEW: Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1 -byte join priority. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in <xref target="sec_channel_hopping" />, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.
OLD: This results in "channel hopping": even with a static schedule, pairs of neighbors "hop" between the different frequencies when communicating. Channel hopping is a technique known to efficiently combat multi-path fading and external interference. NEW: This results in "channel hopping": even with a static schedule, pairs of neighbors "hop" between the different frequencies when communicating. A way of ensuring communication happens on all available frequencies is to set the number of timeslots in a slotframe to a prime number. Channel hopping is a technique known to efficiently combat multi-path fading and external interference.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/23 summary: high level description about joining node behavior OLD: A mote wishing to join the network listens for EBs. Using the ASN and the other timing information of the EB, the new mote synchronizes to the network. Using the slotframe and link information from the EB, it knows how to contact the network. NEW: A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears and EB. What frequency it listen on, of whether it slowly changes frequency during this joining period is implementation-specific. Using the ASN and the other timing information of the EB, the new mote synchronizes to the network. Using the slotframe and link information from the EB, it knows how to contact the network.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/24 summary: clarify use of join priority? Several people have pointed out the need to be more specific about the join priority, including the discussion started at http: //www. ietf. org/mailarchive/web/6 tisch/current/msg 02528. html We need to reach consensus how much of this discussion belongs in the 6 tischtsch draft, and update the draft accordingly. Discussion: before a rewording, we need to agree on whether this belongs in this draft.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/25 summary: clarify use of MLME-TSCH-MODE. request primitive during joining? Several people have pointed out the need to be more specific about the use of the MLME-TSCH-MODE. request primitive during joining. That is, when does a node issue this command. This discussion was ongoing in the thread http: //www. ietf. org/mail-archive/web/6 tisch/current/msg 02528. html We need to reach consensus how much of this discussion belongs in the 6 tischtsch draft, and update the draft accordingly. Discussion: before a rewording, we need to agree on whether this belongs in this draft.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 1 The IEEE 802. 15. 4 e standard [IEEE 802154 e] was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE 802. 15. 4 -2011 [IEEE 802154] standard. The Timeslotted Channel Hopping (TSCH) mode of IEEE 802. 15. 4 e is the object of this document. => could we indicate that it will be merged in the next version (is that going to be IEEE 802. 15. 4 -2015? ) OLD: The IEEE 802. 15. 4 e standard <xref target="IEEE 802154 e"/> was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE 802. 15. 4 -2011 <xref target="IEEE 802154"/> standard. The Timeslotted Channel Hopping (TSCH) mode of IEEE 802. 15. 4 e is the object of this document. NEW: IEEE 802. 15. 4 e <xref target="IEEE 802154 e"/> was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE 802. 15. 4 -2011 <xref target="IEEE 802154"/> standard. IEEE 802. 15. 4 e will be rolled into the next revision of IEEE 802. 15. 4, scheduled to be published in 2015. The Timeslotted Channel Hopping (TSCH) mode of IEEE 802. 15. 4 e is the object of this document.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 2 TSCH was designed to "allow IEEE 802. 15. 4 devices to support a wide range of industrial applications" [IEEE 802154 e]. => could we indicate that its applicability is not necessarily limited to industrial? OLD: TSCH was designed to "allow IEEE 802. 15. 4 devices to support a wide range of industrial applications" <xref target="IEEE 802154 e"/>. At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. This is very different from the "legacy" IEEE 802. 15. 4 MAC protocol, and is therefore better described as a "redesign". TSCH does not amend the physical layer; i. e. , it can operate on any IEEE 802. 15. 4 -compliant hardware. NEW: TSCH was designed to allow IEEE 802. 15. 4 devices to support a wide range of applications including, but not limited to, industrial <xref target="IEEE 802154 e"/>. At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. This is very different from the "legacy" IEEE 802. 15. 4 MAC protocol, and is therefore better described as a "redesign". TSCH does not amend the physical layer; i. e. , it can operate on any IEEE 802. 15. 4 -compliant hardware.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 3 At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. => could we indicate the order of precision that is currently obtained, like 10 s of microseconds or better in some implementations ? OLD: TSCH was designed to allow IEEE 802. 15. 4 devices to support a wide range of applications including, but not limited to, industrial <xref target="IEEE 802154 e"/>. At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. This is very different from the "legacy" IEEE 802. 15. 4 MAC protocol, and is therefore better described as a "redesign". TSCH does not amend the physical layer; i. e. , it can operate on any IEEE 802. 15. 4 -compliant hardware. NEW: TSCH was designed to allow IEEE 802. 15. 4 devices to support a wide range of applications including, but not limited to, industrial <xref target="IEEE 802154 e"/>. At its core is a medium access technique which uses time synchronization to achieve ultra low-power operation and channel hopping to enable high reliability. Synchronization accuracy impacts power consumption, and can vary from micro-seconds to milli-seconds depending on the solution. This is very different from the "legacy" IEEE 802. 15. 4 MAC protocol, and is therefore better described as a "redesign". TSCH does not amend the physical layer; i. e. , it can operate on any IEEE 802. 15. 4 -compliant hardware.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 4 IEEE 802. 15. 4 e can be seen as the latest generation of ultra-lower power and reliable networking solutions for LLNs. [RFC 5673] discusses industrial applications, and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial environment. => maybe insist on the vast amounts of metallic equipment that creates a terrible environment for radios, with a lot of self-induced as well as co channel interference? OLD: IEEE 802. 15. 4 e can be seen as the latest generation of ultra-lower power and reliable networking solutions for LLNs. <xref target="RFC 5673"/> discusses industrial applications, and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial environment. Commercial networking solutions are available today in which motes consume 10's of micro-amps on average <xref target="Current. Calculator"/> with end-to-end packet delivery ratios over 99. 999% <xref target="doherty 07 channel"/>. NEW: IEEE 802. 15. 4 e is the latest generation of ultra-lower power and reliable networking solutions for LLNs. <xref target="RFC 5673"/> discusses industrial applications, and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial environment. In these environments, vast deployment environments with large (metallic) equipment cause multi-path fading and interference to thwart any attempt of a single-channel solution to be reliable; the channel agility of TSCH is the key to its ultra high reliability. Commercial networking solutions are available today in which motes consume 10's of micro-amps on average <xref target="Current. Calculator"/> with end-to-end packet delivery ratios over 99. 999% <xref target="doherty 07 channel"/>.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 5 IEEE 802. 15. 4 e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv 6 enabled protocol stack for LLNs, running 6 Lo. WPAN [RFC 6282], RPL [RFC 6550] and Co. AP [RFC 7252]. => we need to insist that there is a missing LLC layer between the IP abstraction of a link and the TSCH MAC, that is is charge in particular to schedule a timeslot for a given packet coming down the stack from the upper layer. I'd suggest to move this paragraph below the next one, so as to continue on the LLC operations that are described there. OLD: <t> IEEE 802. 15. 4 e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv 6 enabled protocol stack for LLNs, running 6 Lo. WPAN <xref target="RFC 6282"/>, RPL <xref target="RFC 6550"/> and Co. AP <xref target="RFC 7252"/>. </t> <t> Bringing industrial-like performance into the LLN stack developed by the 6 Lo. WPAN, ROLL and Co. RE working groups opens up new application domains for these networks. Sensors deployed in smart cities <xref target="RFC 5548"/> will be able to be installed for years without needing battery replacement. "Umbrella" networks will interconnect smart elements from different entities in smart buildings <xref target="RFC 5867"/>. Peel-and-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes <xref target="RFC 5826"/>. NEW: <t> Bringing industrial-like performance into the LLN stack developed by the 6 Lo. WPAN, ROLL and Co. RE working groups opens up new application domains for these networks. Sensors deployed in smart cities <xref target="RFC 5548"/> will be able to be installed for years without needing battery replacement. "Umbrella" networks will interconnect smart elements from different entities in smart buildings <xref target="RFC 5867"/>. Peel-and-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes <xref target="RFC 5826"/>. </t> <t> IEEE 802. 15. 4 e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv 6 enabled protocol stack for LLNs, running 6 Lo. WPAN <xref target="RFC 6282"/>, RPL <xref target="RFC 6550"/> and Co. AP <xref target="RFC 7252"/>. What is missing is Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is is charge of scheduling a timeslot for a given packet coming down the stack from the upper layer.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 6 => Please expand the acronyms on first use: the Constrained Application Protocol (Co. AP) the IPv 6 Routing Protocol for Low power and Lossy Networks (RPL) OLD: IEEE 802. 15. 4 e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv 6 enabled protocol stack for LLNs, running 6 Lo. WPAN <xref target="RFC 6282"/>, RPL <xref target="RFC 6550"/> and Co. AP <xref target="RFC 7252"/>. What is missing is Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is is charge of scheduling a timeslot for a given packet coming down the stack from the upper layer. NEW: IEEE 802. 15. 4 e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv 6 enabled protocol stack for LLNs, running 6 Lo. WPAN <xref target="RFC 6282"/>, IPv 6 Routing Protocol for Low power and Lossy Networks (RPL) <xref target="RFC 6550"/> and the Constrained Application Protocol (Co. AP) <xref target="RFC 7252"/>. What is missing is Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is is charge of scheduling a timeslot for a given packet coming down the stack from the upper layer.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 7 by the 6 Lo. WPAN, ROLL and CORE working groups => We might also use work from other WGs such as 6 lo ACE, DICE, SACM. . . What about: "by Io. T related IETF working groups such as 6 Lo, ROLL and CORE" OLD: Bringing industrial-like performance into the LLN stack developed by the 6 Lo. WPAN, ROLL and Co. RE working groups opens up new application domains for these networks. Sensors deployed in smart cities <xref target="RFC 5548"/> will be able to be installed for years without needing battery replacement. "Umbrella" networks will interconnect smart elements from different entities in smart buildings <xref target="RFC 5867"/>. Peeland-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes <xref target="RFC 5826"/>. NEW: Bringing industrial-like performance into the LLN stack developed by Internet of Things (Io. T) related IETF working groups such as 6 Lo, ROLL and Co. RE opens up new application domains for these networks. Sensors deployed in smart cities <xref target="RFC 5548"/> will be able to be installed for years without needing battery replacement. "Umbrella" networks will interconnect smart elements from different entities in smart buildings <xref target="RFC 5867"/>. Peel-and-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes <xref target="RFC 5826"/>.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 8 => Please include a section like below after the intro, it appears to be a good idea even in Informational; you are also missing a security section and a IANA section in the end: <section anchor="ref_for_later" title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL NOT", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC 2119">RFC 2119</xref>. </t> </section> NEW: <section anchor="ref_for_later" title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL NOT", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC 2119">RFC 2119</xref>. </t> </section>
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 9 2. TSCH in the LLN Context => Shouldn't that be "IP over TSCH" or "TSCH in an Io. T context" OLD: Using IEEE 802. 15. 4 e TSCH in an LLN context: Overview, Problem Statement and Goals NEW: Using IEEE 802. 15. 4 e TSCH in an Io. T context: Overview, Problem Statement and Goals
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 10 For these reasons, the 6 Lo. WPAN working group has defined an effective adaptation layer [RFC 6568]. => I think you mean RFC 4944/6282. RFC 6568 is about LLN use cases yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 11 Further issues encompass the auto-configuration of IPv 6 addresses [RFC 2464][RFC 6755], => I think you mean RFC 2460 and 4862 yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 12 Page 4: could you split that very long paragraph? yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 13 Regardless of the way it is computed, the Rank monotonically decreases along the DODAG towards the destination, building a gradient. => "towards the root" would be more acurate yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 14 As highlighted in Appendix A, TSCH is different for traditional lowpower MAC protocols because of its scheduled nature. => maybe "differs from" ? yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 15 generic name "6 Ti. SCH". => Unsure it is a good idea to overload 6 Ti. SCH. Could we use the term LLC instead when referring to the layer? In 3. 1 6 Ti. SCH seems to refer to the WG, which IMHO is more proper. yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 16 3. Schedule transmissions of Enhanced Beacons to advertise the presence of the network. => only in EBs? We need IEs to negotiate timeslots between peers as well, and I understand that these can be in any data frame or ack, correct? While IEs can be in other packets, on the EBs can advertise the network to new motes.
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 17 3. Define rules on when to add or delete links in a particular slotframe. => I think we want to use the term CELL here yes. done
http: //trac. tools. ietf. org/wg/6 tisch/trac/ticket/27#COMMENT 18 => Please include a a security section and a IANA section in the end <section anchor="IANA" title="IANA Considerations"> <t>This memo includes no request to IANA. </t> </section> <section anchor="Security" title="Security Considerations"> <t> Security of the join process is described in section blah. Data frame protection is discussed in section blah. </t> </section> yes. done
6 Ti. SCH Operation Sublayer (6 top) Interface draft-ietf-6 tisch-6 top-interface-01 Qin Wang Xavi Vilajosana Thomas Watteyne
Yang Model 3. Generic Data Model. . . . . 8 3. 1. YANG model of the 6 top MIB. . . . 8 3. 2. YANG model of the IEEE 802. 15. 4 PIB. . . 24
6 top MIB • Status: – Model ready – Reviewed by Carl Moberg (Syntactic review only) -(Yang Model Doctor at IETF 90 th Toronto) – Needs functional and semantic validation and consensus – IMPORTANT: The yang model is the interface of the core of 6 Ti. SCH, i. e how to manage the MIB of 6 top and how to express the configuration and management parameters of 15. 4 e TSCH networks. Requires deep attention.
See tables in document • https: //bitbucket. org/6 tisch/draft-ietf-6 tisch 6 topinterface/src/master/6 top%20 MIB%20 table. docx
15. 4 e MIB • Status: – Model almost ready – Just setters and getters of 15. 4 e PIB attributes – Reviewed by Carl Moberg (Syntactic review) -- (Yang Model Doctor at IETF 90 th Toronto) – Needs functional and semantic validation and consensus – TODO still to be addressed related to the security model. • OPTIONS ARE: – a) 6 top offers security configuration semantics and offers Yang Model abstraction for it – b) PIB security related attributes are handled outside of 6 top – Check it here: • https: //bitbucket. org/6 tisch/draft-ietf-6 tisch-6 topinterface/src/master/draft-ietf-6 tisch-6 top-interface-02. txt
Call for review • Please send your comments and considerations to the ML.
Compressing the RPL information (RFC 6550/3)
Status Flow Label solution started WGLC at 6 MAN Laurent Toutain suggested a 6 Lo. WPAN-based compression Carsten Bormann and then Pascal continued the idea and proposed their own variations This debate lost the 6 MAN focus – activity stalled Debate at 6 lo on how much footprint we could steal from 6 Lo. WPAN formats and where from – activity quite stalled too
Flow Label vs. 6 Lo. WPAN Both solutions work for 6 Ti. SCH since 6 Ti. SCH uses 6 Lo. WPAN anyway • But no commitment from 6 lo side Dependency for minimal draft, shipping in November • What will an implementation do till 6 lo delivers ? Dependency for track ID • Architecture says to use the flow label • The 6 Lo. WPAN compression could be adapted
The RFC Style Guide RFC 7322 http: //www. rfceditor. org/styleguide. html
RFC 7322: "RFC Style Guide" The RPC is manually fixing these items, while the tools do not yet provide this functionality: Section 4: Unnumbered sections (related ticket for xml 2 rfc v 2) Section 4. 8. 6. 3: Referencing STDs and BCPs (related ticket for xml 2 rfc v 2) Section 4. 8. 6. 4: Referencing Internet-Drafts "Authors' Addresses" will appear in the Table of Contents (related ticket for xml 2 rfc v 2) Note that some of these fixes occur in the final stages of the publication process; i. e. , the changes are applied to 47 the. nroff file to get the required. txt output.
Web Portion of the Style Guide – detailed hereafter Status of This Memo Boilerplate - "Status of This Memo" text as defined by RFC 5741 Abbreviations List - Expansions of abbreviations (and acronyms) in RFCs Terms List - Table of decisions on consistent usage in RFCs IAB Format - IAB-specific format for RFCs in the IAB stream. Old materials (replaced by the documents above): RFC Editorial Policies - A collection of policies on RFC editorial issues. "Instructions to RFC Authors" - A draft replacement for RFC 2223. 48
No expansion This list includes some terms that look like abbreviations but are actually fixed names for things, and hence cannot and should not be expanded. These are noted as "No expansion". ----------------------------------- • … • 6 CO - 6 Lo. WPAN Context Option (6 CO) (RFC 6775) • 6 LBR - 6 Lo. WPAN Border Router (6 LBR) (RFC 6345) • 6 LN - 6 Lo. WPAN Node (6 LN) (RFC 6775) • 6 Lo. WPANs - IPv 6 over Low-Power Wireless Personal Area Networks (6 Lo. WPANs) (RFC 4919) • 6 LR - 6 Lo. WPAN Router (6 LR) (RFC 6606) • …
MUSTs • RFC numbers may be used as modifiers in running text, but they must appear as follows: no hyphens between "RFC" and the number (e. g. , RFC-5011 style rollover); a space should appear between the RFC and the number (e. g. , RFC 5011 style rollover) • avoid hyphenating citations with text (e. g. , don't use [RFC 5011]-style rollover) • if the sentence is unclear or potentially confusing, the sentence will be rewritten when possible. Otherwise, the issue will be raised with the authors for discussion.
RECOMMENDED Length of Sections All RFCs are naturally divided in to sections. We recommend that the length of a section or subsection be limited to allow for easily referenced objects. Avoid using abbreviations as verbs when possible. If Abbreviations unavoidable, suffixes should be affixed without punctuation, as Verbs for example, "XORed" (not XOR'ed) and "NATed" (not NATed). Expanding Abbreviations should be expanded upon first use. The abbreviations abbreviated form should be used thereafter. upon first use Use of didactic capitalization is not needed. For example: Extensible Markup Language (XML) (not Didactic Capitalization EXtensible Markup Language (XML) or e. Xtensible Markup Language (XML))
RECOMMENDED (con’t) In-text Citations (bracketed citation) An in-text citation may a) be read as part of the text or b) follow the subject for which it is being cited. For example: a)As part of the transition to IPv 6, NAT 64 [RFC 6146] and DNS 64 [RFC 6147] technologies will be utilized by some access networks to provide IPv 4 connectivity for IPv 6 -only nodes [RFC 6144]. or b) Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC 6959]. We recommend using a) and strongly recommend consistent use of one style throughout. • This is mostly left to author preference. However, note the following: Referring to Instances of "[RFCXXXX] section N. N" will be updated as "[RFCXXXX], specific Section N. N" in most cases. sections within • If that format may be unclear, the text will be updated as "Section N. N another of [RFCXXXX]". document • If neither option works for some reason, a question will be sent to the authors.
AOB ?
Thank you!
- Slides: 54