Skip to main content

Reliable and Available Wireless
charter-ietf-raw-00-00

Revision differences

Document history

Date Rev. By Action
2021-03-10
00-00 Cindy Morgan Responsible AD changed to John Scudder from Deborah Brungard
2020-02-07
01 Cindy Morgan New version available: charter-ietf-raw-01.txt
2020-02-07
00-04 Cindy Morgan State changed to Approved from External Review (Message to Community, Selected by Secretariat)
2020-02-07
00-04 Cindy Morgan IESG has approved the charter
2020-02-07
00-04 Cindy Morgan Closed "Approve" ballot
2020-02-07
00-04 Cindy Morgan WG action text was changed
2020-02-07
00-04 Deborah Brungard
Changed charter milestone "Evaluation of Existing IETF Tools and Gap Analysis Document submit to IESG", set description to "Evaluation of Existing IETF Technologies and Gap …
Changed charter milestone "Evaluation of Existing IETF Tools and Gap Analysis Document submit to IESG", set description to "Evaluation of Existing IETF Technologies and Gap Analysis Document submit to IESG"
2020-02-07
00-04 Deborah Brungard
Changed charter milestone "Working Group Adoption of Evaluation of Existing IETF Tools and Gap Analysis Document", set description to "Working Group Adoption of Evaluation of …
Changed charter milestone "Working Group Adoption of Evaluation of Existing IETF Tools and Gap Analysis Document", set description to "Working Group Adoption of Evaluation of Existing IETF Technologies and Gap Analysis Document"
2020-02-07
00-04 Deborah Brungard New version available: charter-ietf-raw-00-04.txt
2020-02-06
00-03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-02-05
00-03 Benjamin Kaduk
[Ballot comment]
I don't understand what the "other IETF tools" in "RAW’s primary focus is on
identifying areas where the DetNet adaptation to wireless networks …
[Ballot comment]
I don't understand what the "other IETF tools" in "RAW’s primary focus is on
identifying areas where the DetNet adaptation to wireless networks and
other IETF tools may require additional supporting mechanisms" are supposed
to be.  Are they IETF protocols?

There may be some grammatical tweaks possible to improve "If solution work
is needed, it will be coordinated on where the work will be done" (with respect
to "it will be coordinated", notably).
2020-02-05
00-03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-02-05
00-03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-02-05
00-03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-02-05
00-03 Alissa Cooper [Ballot comment]
Thanks for addressing my comments.
2020-02-05
00-03 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Block
2020-02-05
00-03 Deborah Brungard New version available: charter-ietf-raw-00-03.txt
2020-02-04
00-02 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-02-04
00-02 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-02-04
00-02 Alvaro Retana
[Ballot comment]
I support the first part of Alissa's BLOCK.


This may be a nit, but I still find this sentence a little confusing: "Additional …
[Ballot comment]
I support the first part of Alissa's BLOCK.


This may be a nit, but I still find this sentence a little confusing: "Additional documents may be published or exist on a git repository, the publication format will be agreed by the Working Group at the time the document is adopted by the group." 

The fact that the milestones point at RFCs seems to clarify the meaning of "published"; but the alternative to an RFC ("published") is more akin to a draft and not a document that exists in an external repository only.  IOW, I would hope that if additional documents exist, that they do so either as an internet-draft or an RFC.  This state is independent of the tools used for its development.
2020-02-04
00-02 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-02-04
00-02 Deborah Brungard Added charter milestone "Evaluation of Existing IETF Tools and Gap Analysis Document submit to IESG", due June 2021
2020-02-04
00-02 Deborah Brungard Added charter milestone "Architecture/Framework Aspects for a Wireless Network Document submit to IESG", due April 2021
2020-02-04
00-02 Deborah Brungard Added charter milestone "Requirements Document submit to IESG", due December 2020
2020-02-04
00-02 Deborah Brungard Added charter milestone "Working Group Adoption of Evaluation of Existing IETF Tools and Gap Analysis Document", due December 2020
2020-02-04
00-02 Deborah Brungard Added charter milestone "Use Cases Document submit to IESG", due November 2020
2020-02-04
00-02 Deborah Brungard Added charter milestone "Working Group Adoption of Architecture/Framework Aspects for a Wireless Network Document", due November 2020
2020-02-04
00-02 Deborah Brungard Added charter milestone "Working Group Adoption of Requirements Document", due September 2020
2020-02-04
00-02 Deborah Brungard Added charter milestone "Working Group Adoption of Use Cases Document", due September 2020
2020-02-04
00-02 Alissa Cooper
[Ballot block]
I still feel that the charter is unclear on the relationship between "Aeronautical Data Applications" and the work of this WG. The charter …
[Ballot block]
I still feel that the charter is unclear on the relationship between "Aeronautical Data Applications" and the work of this WG. The charter says this is "one" critical application, but then uses the term "these newly identified industry applications" and "these newer industry applications." Do those snippets of text refer to multiple different aeronautical applications? Or do they refer to applications in other domains? Since the aeronautical applications are called out multiple times, are they expected to take precedence over other applications when the use cases and requirements are defined?

Also, this is a little pedantic but since there has been a lot of confusion about this, I think it needs to be clarified: the charter says "RAW’s focus will be on identifying use cases and
requirements for these new applications." Wouldn't we expect applications to flow from use cases, not the other way around? That is, if the WG intends to invent use cases for applications that already exist, that seems backwards.
2020-02-04
00-02 Alissa Cooper [Ballot Position Update] New position, Block, has been recorded for Alissa Cooper
2020-02-04
00-02 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-02-04
00-02 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-02-03
00-02 Mirja Kühlewind [Ballot Position Update] New position, Abstain, has been recorded for Mirja Kühlewind
2020-02-03
00-02 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-01-29
00-02 Cindy Morgan Telechat date has been changed to 2020-02-06 from 2020-01-23
2020-01-29
00-02 Cindy Morgan Created "Approve" ballot
2020-01-29
00-02 Cindy Morgan Closed "Ready for external review" ballot
2020-01-29
00-02 Cindy Morgan State changed to External Review (Message to Community, Selected by Secretariat) from Start Chartering/Rechartering (Internal IESG/IAB Review)
2020-01-29
00-02 Cindy Morgan WG new work message text was changed
2020-01-29
00-02 Cindy Morgan WG review text was changed
2020-01-29
00-02 Cindy Morgan WG review text was changed
2020-01-29
00-02 Cindy Morgan WG review text was changed
2020-01-29
00-02 Deborah Brungard New version available: charter-ietf-raw-00-02.txt
2020-01-29
00-01 Magnus Westerlund [Ballot comment]
I think there are still some acronyms that could benefit from expansion, such as DLEP.
2020-01-29
00-01 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Block
2020-01-29
00-01 Deborah Brungard New version available: charter-ietf-raw-00-01.txt
2020-01-23
00-00 Alexey Melnikov [Ballot comment]
I am personally not a big fan of WGs that restricted to working on requirements/use cases, but I don't feel strongly about this.
2020-01-23
00-00 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2020-01-23
00-00 Suresh Krishnan [Ballot comment]
Alvaro cover everything I wanted to say and more. So a big +1 for his position.
2020-01-23
00-00 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2020-01-23
00-00 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-01-23
00-00 Magnus Westerlund
[Ballot block]
This is not a particular hard Block. However, I think the sum of the comments from the IESG recommends substantial rewording on the …
[Ballot block]
This is not a particular hard Block. However, I think the sum of the comments from the IESG recommends substantial rewording on the charter before it going out for external review. I at least would like to see the reworked charter before giving it a go-ahead to sending it out for external review. I personally are especially interested if it can be clarified what the WG actually is expected to produce.

I also have to ask the question, is Routing the right area? A lot of the text appears to talk about issues that would be more at home in INT? This appears to take a more architectural gap analysis. I understand that there is overlap into both areas. However, if the target is to produce a gap analysis to figure out where there are short comings in the IETF suit of protocols, are there going to be any effort into identifying issues using this network for transport protocols?

The LDACS text appears to implicitly indicate that the WG should consider how to provide an IP solution for them. If such work is to be done I think that needs its own home. Can the below part be changed to not imply such work:

" The Aeronautical standards work on a physical layer and data
link layer for data communications is reaching maturity and there is
significant interest in developing an IP connectivity solution."
2020-01-23
00-00 Magnus Westerlund Ballot discuss text updated for Magnus Westerlund
2020-01-23
00-00 Magnus Westerlund
[Ballot block]
I think the sum of the comments from the IESG require substantial work on the charter before it going out for external review. …
[Ballot block]
I think the sum of the comments from the IESG require substantial work on the charter before it going out for external review. I at least would like to see the reworked charter before sending it out.

I also have to ask the question, is Routing the right area? A lot of the text appears to talk about issues that would be more at home in INT? This appears to take a more architectural gap analysis. I understand that there is overlap into both areas.

The LDACS text appears to implicitly indicate that the WG should consider how to provide an IP solution for them. If such work is to be done I think that needs its own home. Can the tone especially in this part be changed?:

" The Aeronautical standards work on a physical layer and data
link layer for data communications is reaching maturity and there is
significant interest in developing an IP connectivity solution."
2020-01-23
00-00 Magnus Westerlund [Ballot Position Update] New position, Block, has been recorded for Magnus Westerlund
2020-01-22
00-00 Benjamin Kaduk
[Ballot comment]
More "+1 Alvaro" here.

  additional supporting mechanisms. The RAW Working Group will also examine the
  applicability of other existing IETF work, …
[Ballot comment]
More "+1 Alvaro" here.

  additional supporting mechanisms. The RAW Working Group will also examine the
  applicability of other existing IETF work, e.g., DLEP. The RAW Working Group

(side note: will be interesting to see how to address DLEP's non-security
for such new use cases.)

  deployment problems. RAW is not chartered to work on a solution, if solution
  work is needed in addition to the DetNet solution work or other existing
  solution work in the IETF, it will be coordinated on where the work will be
  done. [...]

nit: comma splice
2020-01-22
00-00 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-01-22
00-00 Adam Roach
[Ballot comment]
I had several comments that I was about to write up when I discovered that Alvaro had covered them all quite handily. So …
[Ballot comment]
I had several comments that I was about to write up when I discovered that Alvaro had covered them all quite handily. So +1 to Alvaro's comments. No objection to going to external review, but I would probably block approval on a charter that wasn't clearer about the precise final form of its intended outputs.
2020-01-22
00-00 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-01-22
00-00 Martin Vigoureux
[Ballot comment]
Hello,

it is not clear to me what these sentences mean:
  The documents may exist individually or on a git repository.
Does …
[Ballot comment]
Hello,

it is not clear to me what these sentences mean:
  The documents may exist individually or on a git repository.
Does it mean that no draft could ever be published and that contributions could only be made and stored on github?

  The Use Case document may consist of one or more documents to allow users/operators the opportunity to provide
  comprehensive deployment plans for these new (to IETF) technologies.
What are the technologies being referred to here?
2020-01-22
00-00 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-01-22
00-00 Roman Danyliw
[Ballot comment]
+1 on Alvaro Retana’s feedback.

To the question of how will the WG know they covered all of the use cases, are the …
[Ballot comment]
+1 on Alvaro Retana’s feedback.

To the question of how will the WG know they covered all of the use cases, are the “newer industrial applications” referenced in “The RAW Working Group is planned to … quickly address these newer industry applications”: (a) “Aeronautical Data Communications” or (b) “IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS)”?

(Not my area) Is it possible to be clearer on the purpose of the draft artifacts? If the need for new “solution work” is unclear, then why is there certainty that more supporting documents are needed?
2020-01-22
00-00 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-01-21
00-00 Alissa Cooper
[Ballot comment]
I think it's possible to go to external review with this charter now, but I think it would be much better to get …
[Ballot comment]
I think it's possible to go to external review with this charter now, but I think it would be much better to get clear answers to the questions Alvaro raises in his ballot before putting it out to external review. I had many of the same questions when reading this.

In particular, one rationale for publishing informational documents as RFCs is to ease coordination with other SDOs. In this case it's unclear whether the documents are intended to be published as RFCs, and the charter says there will be no coordination with SDOs, including wherever the aeronautical standards are being developed. This seems like a bit of a contradiction to me. If RFCs are needed for alignment and coordination, then we should coordinate. And if not, then I wonder whether drafts will be sufficient.
2020-01-21
00-00 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-01-21
00-00 Alvaro Retana Responsible AD changed to Deborah Brungard
2020-01-21
00-00 Mirja Kühlewind
[Ballot comment]
I'm uncertain what to ballot here, so I'll abstain.

It's unclear to me which if any documents the working group will produce. I …
[Ballot comment]
I'm uncertain what to ballot here, so I'll abstain.

It's unclear to me which if any documents the working group will produce. I agree with Alvaro that is would be good to be more explicit about this to support the chairs and future ADs.

I also still don't quite understand why this is not part of the DetNet group. It seems that the DetNet people have to go to this group anyway. So why not adding it the DetNet charter and the chairs could just e.g. request two sessions at the meeting and use this to split the discussion. Such an approach would enable a much smoother and hopefully faster convergence to solution work if any is needed.
2020-01-21
00-00 Mirja Kühlewind [Ballot Position Update] New position, Abstain, has been recorded for Mirja Kühlewind
2020-01-21
00-00 Éric Vyncke
[Ballot comment]
I am trusting the routing AD for the relevance of this work. Also interested in the "L-band Digital Aeronautical Communications System (LDACS)" mention …
[Ballot comment]
I am trusting the routing AD for the relevance of this work. Also interested in the "L-band Digital Aeronautical Communications System (LDACS)" mention in the charter. Unsure whether it is worth mentioning the ATN mailing list.

See: https://www.ietf.org/mailman/listinfo/atn

-éric
2020-01-21
00-00 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-01-20
00-00 Alvaro Retana
[Ballot comment]
I am usually wary of chartering WGs to produce supporting documents such as use cases and requirements.  On one hand I believe these …
[Ballot comment]
I am usually wary of chartering WGs to produce supporting documents such as use cases and requirements.  On one hand I believe these documents are important to the eventual solutions work.  On the other hand, it concerns me that the solutions might be delayed while the support documents work through publication, or that the support documentation might loose their relevance during that time.  In this case, addressing the applications of a new-to-the-IETF community, and producing documents that may be of external interest is important.  There are a couple of related details that I would like to see specifically addressed in the charter (+ milestones):

- The timeframe is short (12-18 months), but the list of work items is significant.  The milestones need to be properly prioritized and closely managed.

- Specifically related to Use Cases, the text says that "the Use Case document may consist of one or more documents".  One of the milestones should point to a date when no more use cases will be accepted in the WG -- this is to avoid late submissions from not letting the WG continue/finish the work in the short timeframe.

- The text about the "documents may exist individually or on a git repository" hints at the possibility of not publishing all the documents as RFCs, but it is not explicit about it.  I would like the Charter to explicitly talk about alternate publication mechanisms, and, if possible, define upfront which documents should be published as RFCs and which shouldn't.  Guiding the WG to make those decisions early, and empowering the Chairs (in the Charter) to enforce them is important.



Other comments:

- Is there a reference to the "Aeronautical standards work"?  Is it important to coordinate with the body producing them?

- The third paragraph mentions "these new applications" at least 3 times...but there is no clear indication of what those are, except for the "One critical application is Aeronautical Data Communications."  If the work wants to be scoped and focused, then the charter should be a little more specific about the applications.

- [nit] "The RAW Working Group will also examine..."  Start a new paragraph there...
2020-01-20
00-00 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-01-18
00-00 Barry Leiba
[Ballot comment]
I was looking for more differentiation of the work, but as the relevant ADs feel that the vagueness is useful for getting the …
[Ballot comment]
I was looking for more differentiation of the work, but as the relevant ADs feel that the vagueness is useful for getting the right discussions going, and given that it is -- as is quite clear in the charter -- just for discussion and Informational exposition now, I'm fine with this as it is.
2020-01-18
00-00 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from No Record
2020-01-18
00-00 Barry Leiba
[Ballot comment]
Before I record a specific position, I’d like to understand more here:

1.  As it’s written, except for the stated connections to DETNET …
[Ballot comment]
Before I record a specific position, I’d like to understand more here:

1.  As it’s written, except for the stated connections to DETNET and MANET this sounds more like an INT area working group than one in RTG. Can it be clearer as to why it’s about routing?

2. Given how tightly connected it is to DETNET, why does it make sense to separate it out in its own working group?  Won’t it simply be the same people, just dividing their time between the two?  How does the separation help get the collective work between the two groups done?
2020-01-18
00-00 Barry Leiba Ballot comment text updated for Barry Leiba
2020-01-17
00-00 Cindy Morgan Telechat date has been changed to 2020-01-23 from 2020-02-06
2020-01-17
00-00 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-01-17
00-00 Cindy Morgan Placed on agenda for telechat - 2020-02-06
2020-01-17
00-00 Cindy Morgan WG action text was changed
2020-01-17
00-00 Cindy Morgan WG review text was changed
2020-01-17
00-00 Cindy Morgan WG review text was changed
2020-01-17
00-00 Cindy Morgan Created "Ready for external review" ballot
2020-01-17
00-00 Cindy Morgan State changed to Start Chartering/Rechartering (Internal IESG/IAB Review) from Not currently under review
2020-01-17
00-00 Cindy Morgan New version available: charter-ietf-raw-00-00.txt