Subject: [Tsv-art] ACTION NEEDED: TSV reviewers for IETF LC/near-LC documents as of 9/26

From: Allison Mankin <[email-masked]>
Date: Mon, 26 Sep 2016 14:06:18 -0400

Dear TSV ART-isans,

I reviewed all documents that are in IETF LC and LC Requested as of 9/26.
I also looked at AD Review state as a proxy for documents that recently
passed through WGLC.  Please find below all documents that I believe need
TSV review attention.  Your Action Needed is to volunteer to write a
tsv-art review for one or more of these.

The reason we've added some documents to get earlier reviews to increase
the regularity of reviews being asked of you in the tsv-art (and, also,
earlier review is good).  Currently we count on you to volunteer, rather
than trying to dispatch assignments.  Perhaps seeing documents earlier will
help you to consistently offer 1-2 reviews per month to support Spencer and
Mirja.

If you agree that a document needs review by someone of your expertise, but
you are too busy, we'll be very happy for you to identify and ask another
person with your expertise to do the review.  Just let us know by cc'ing
[email-masked].  This will also help us to expand the tsv-art.

In the document lists, if a date is present, it signifies the end of the
IETF LC.  To help you decide to review, I've included a quick cut at the
TSV topic needing attention (in brackets), but don't consider these hints
to be comprehensive.

*Documents that require TSV attention*
Last Calls
- draft-ietf-ipsecme-ddos-protection-09 [congestion/rate control] - 9/28
- draft-ietf-opsawg-capwap-alt-tunnel-08 [tunneling] - 9/30
- draft-ietf-straw-b2bua-rtcp-13.txt [ECN] - 10/10
AD Review
- draft-ietf-6lo-6lobac-05.txt [MTU]
- draft-ietf-6lo-dect-ule-05.txt [MTU]
- draft-ietf-manet-credit-window-04 [receiver-based flow control over TCP?]
- draft-ietf-sidr-rpki-rtr-rfc6810-bis-07.txt [updated tsv requirements]

*Documents that may require TSV attention*
AD Review
- draft-ietf-6tisch-minimal-16.txt [link-level rxt]
- draft-ietf-ccamp-ospf-availability-extension-06.txt [advertising link
discrete variable bws]
- draft-ietf-manet-dlep-24.txt [dynamic link exchange carried by TCP]
- draft-ietf-webpush-protocol-09.txt [https-level reliability to devices]

*Documents that do not require TSV attention*
Last Call
- draft-ietf-cose-msg-18
- draft-ietf-6lo-paging-dispatch-04
- draft-ietf-ippm-6man-pdm-option-06 [TSV doc]
- draft-ietf-ipsecme-safe-curves-04
- draft-ietf-lisp-crypto-07
- draft-ietf-lisp-lcaf-15
- draft-ietf-regext-epp-rdap-status-mapping-01
- draft-ietf-stox-7248bis-12
- draft-ietf-tictoc-multi-path-synchronization-05.txt
- draft-levine-herkula-oneclick-06.txt
- draft-murchison-nntp-compress-05.txt
- draft-weis-gdoi-iec62351-9-08.txt
AD Review
- draft-adid-urn-00.txt
- draft-holmberg-dispatch-mcptt-rp-namespace-02.txt
- draft-ietf-6lo-privacy-considerations-03.txt
- draft-ietf-appsawg-mdn-3798bis-12.txt
- draft-ietf-behave-syslog-nat-logging-06 [TSV doc]
- draft-ietf-l3sm-l3vpn-service-model-15.txt
- draft-ietf-netconf-yang-patch-11.txt
- draft-ietf-p2psip-share-08.txt
- draft-ietf-payload-rtp-ancillary-05.txt
- draft-ietf-pim-join-attributes-for-lisp-04.txt
- draft-ietf-roll-routing-dispatch-01.txt
- draft-ietf-savi-mix-11.txt
- draft-ietf-sfc-control-plane-07.txt
- draft-ietf-sidr-bgpsec-protocol-18.txt
- draft-sparks-genarea-interim-management-00.txt
- draft-sparks-genarea-manualpost-tracking-00.txt
- draft-spinosa-urn-lex-09.txt

Regards,

  Allison (on Triage duty)

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Sep 2016 11:38:15 -0700

Hi, all,

I'd like to provide some targeted feedback, if useful, on tunnel and MTU
issues noted below, in light of the INTAREA tunnels document I've been
working on.  I'm not sure any of these three documents needs more of a
transport review than this. If useful, let me know and I can forward to
each group separately.

Joe

----

tunnel:

draft-ietf-opsawg-capwap-alt-tunnel-08 - this doc refers off to existing
tunneling specifications, many of which are inconsistent or incorrect
(i.e., they violate requirements at the IP layer), as already noted in
draft-intarea-tunnels. It would be useful for this protocol to include
signalling to indicate the receiver payload reassembly limit when
indicating support for each tunnel type, to assist the source in
determining whether the resulting tunnel will be IPv6 compliant (rather
than becoming a black hole for valid packet sizes). Additionally, for
the transport protocol-based tunnels, it would be useful to indicate not
only the endpoint IP address but the port number as well. Finally, it
might be useful to consider IPsec TLS, and DTLS tunnels as well as those
already listed.

----

MTU:

draft-ietf-6lo-6lobac-05.txt - the protocol supports1280-1500B payloads
without fragmentation and uses its own link header; as a result, this is
sufficient for IPv6 and there should be no new interaction with TCP or
other transports.

----

draft-ietf-6lo-dect-ule-05.txt- Sec 2.4 indicates that the default MTU
for DECT UL is 500 octets and does note that:

   ...In order to
   support complete IP packets, the DLC layer of DECT ULE SHALL per this
   specification be configured with a MTU size that fits the
   requirements from IPv6 data packets, hence [RFC4944 <https://tools.ietf.org/html/rfc4944>] fragmentation/
   reassembly is not required.

IMO, this text should he changed to be more clear about this referring
to IPv6 only (as per the title of the doc), to indicate the minimum MTU,
and to explain the reference to RFC4944:

    ...In order to support IPv6, the DLC layer of DECT ULE MUST be
    configured with a MTU of at least 1280B to avoid the need for
    an RFC4944-style shim layer for additional support for larger
    payload fragmentation/reassembly."

----

On 9/26/2016 11:06 AM, Allison Mankin wrote:
> Dear TSV ART-isans,
>
> I reviewed all documents that are in IETF LC and LC Requested as of
> 9/26.  I also looked at AD Review state as a proxy for documents that
> recently passed through WGLC.  Please find below all documents that I
> believe need TSV review attention.  Your Action Needed is to volunteer
> to write a tsv-art review for one or more of these.
>
> The reason we've added some documents to get earlier reviews to
> increase the regularity of reviews being asked of you in the tsv-art
> (and, also, earlier review is good).  Currently we count on you to
> volunteer, rather than trying to dispatch assignments.  Perhaps seeing
> documents earlier will help you to consistently offer 1-2 reviews per
> month to support Spencer and Mirja.
>
> If you agree that a document needs review by someone of your
> expertise, but you are too busy, we'll be very happy for you to
> identify and ask another person with your expertise to do the review. 
> Just let us know by cc'ing [email-masked]
> <mailto:[email-masked]>.  This will also help us to expand the
> tsv-art.
>
> In the document lists, if a date is present, it signifies the end of
> the IETF LC.  To help you decide to review, I've included a quick cut
> at the TSV topic needing attention (in brackets), but don't consider
> these hints to be comprehensive.
>
> _Documents that require TSV attention_
> Last Calls
> - draft-ietf-ipsecme-ddos-protection-09[congestion/rate control] - 9/28
> _Documents that may require TSV attention_
> AD Review
> - draft-ietf-ccamp-ospf-availability-extension-06.txt [advertising
> link discrete variable bws]
> _Documents that do not require TSV attention_
> Last Call
> - draft-ietf-cose-msg-18
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Allison Mankin <[email-masked]>
Date: Mon, 26 Sep 2016 15:05:28 -0400

Joe,

I don't think more is needed for the drafts than these comments (they're
fresh in my mind).

Please do send a TSV ART Last Call review with the comment about capwap to
that group?

The comment about 6lo-dect-ule could be sent as a TSV ART early review - we
don't have a format for this (yet) but I think it's fine to just use the
TSV ART early review in subject line and ask them to address the comment in
their revisions prior to or during IETF LC.

AD not on vacation (Spencer), what do you think?

Thanks!!

On 26 September 2016 at 14:38, Joe Touch <[email-masked]> wrote:

> than becoming a black hole for valid packet sizes). Additionally, for the
> transport protocol-based tunnels, it would be useful to indicate not only
> the endpoint IP address but the port number as well. Finally, it might be
> useful to consider IPsec TLS, and DTLS tunnels as well as those already
> listed.
>
> ----
>
> MTU:
>
> IMO, this text should he changed to be more clear about this referring to
> IPv6 only (as per the title of the doc), to indicate the minimum MTU, and
> to explain the reference to RFC4944:
>
> If you agree that a document needs review by someone of your expertise,
> but you are too busy, we'll be very happy for you to identify and ask
> another person with your expertise to do the review.  Just let us know by
> cc'ing [email-masked].  This will also help us to expand the tsv-art.
>
> Tsv-art mailing [email-masked]://www.ietf.org/mailman/listinfo/tsv-art
>
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 26 Sep 2016 15:31:09 -0500

Hi, Allison,

On Mon, Sep 26, 2016 at 2:05 PM, Allison Mankin <[email-masked]>
wrote:

> The comment about 6lo-dect-ule could be sent as a TSV ART early review -
> we don't have a format for this (yet) but I think it's fine to just use the

That works for me - and thank you, Joe, for providing the feedback so
quickly.

Spencer, as AD "on the clock"

>> believe need TSV review attention.  Your Action Needed is to volunteer to
>> write a tsv-art review for one or more of these.
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Sep 2016 14:02:36 -0700

On 9/26/2016 12:05 PM, Allison Mankin wrote:
> Joe,
>
> I don't think more is needed for the drafts than these comments
> (they're fresh in my mind).
>
> Please do send a TSV ART Last Call review with the comment about
> capwap to that group?
The email group appears to be gone - I just tried to subscribe here:
https://datatracker.ietf.org/wg/capwap/charter/

>
> The comment about 6lo-dect-ule could be sent as a TSV ART early review
> - we don't have a format for this (yet) but I think it's fine to just
> use the TSV ART early review in subject line and ask them to address
> the comment in their revisions prior to or during IETF LC.
Will do. Should I also send one about the doc with no issues?

Joe

> On 26 September 2016 at 14:38, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi, all,
>
>     I'd like to provide some targeted feedback, if useful, on tunnel
>     and MTU issues noted below, in light of the INTAREA tunnels
>     document I've been working on.  I'm not sure any of these three
>     documents needs more of a transport review than this. If useful,
>     let me know and I can forward to each group separately.
>
>     Joe
>
>     ----
>
>     tunnel:
>
>     draft-ietf-opsawg-capwap-alt-tunnel-08 - this doc refers off to
>     existing tunneling specifications, many of which are inconsistent
>     or incorrect (i.e., they violate requirements at the IP layer), as
>     already noted in draft-intarea-tunnels. It would be useful for
>     this protocol to include signalling to indicate the receiver
>     payload reassembly limit when indicating support for each tunnel
>     type, to assist the source in determining whether the resulting
>     tunnel will be IPv6 compliant (rather than becoming a black hole
>     for valid packet sizes). Additionally, for the transport
>     protocol-based tunnels, it would be useful to indicate not only
>     the endpoint IP address but the port number as well. Finally, it
>     might be useful to consider IPsec TLS, and DTLS tunnels as well as
>     those already listed.
>
>     ----
>
>     MTU:
>
>     draft-ietf-6lo-6lobac-05.txt - the protocol supports1280-1500B
>     payloads without fragmentation and uses its own link header; as a
>     result, this is sufficient for IPv6 and there should be no new
>     interaction with TCP or other transports.
>
>     ----
>
>
>     draft-ietf-6lo-dect-ule-05.txt- Sec 2.4 indicates that the default
>     MTU for DECT UL is 500 octets and does note that:
>
>        ...In order to
>     IMO, this text should he changed to be more clear about this
>     referring to IPv6 only (as per the title of the doc), to indicate
>     the minimum MTU, and to explain the reference to RFC4944:
>
>>     I reviewed all documents that are in IETF LC and LC Requested as
>>     of 9/26.  I also looked at AD Review state as a proxy for
>>     documents that recently passed through WGLC.  Please find below
>>     all documents that I believe need TSV review attention.  Your
>>     Action Needed is to volunteer to write a tsv-art review for one
>>     or more of these.
>>
>>     increase the regularity of reviews being asked of you in the
>>     tsv-art (and, also, earlier review is good).  Currently we count
>>     on you to volunteer, rather than trying to dispatch assignments. 
>>     Perhaps seeing documents earlier will help you to consistently
>>     offer 1-2 reviews per month to support Spencer and Mirja.
>>
>>     identify and ask another person with your expertise to do the
>>     review.  Just let us know by cc'ing [email-masked]
>>     <mailto:[email-masked]>.  This will also help us to expand
>>     the tsv-art.
>>
>>     In the document lists, if a date is present, it signifies the end
>>     of the IETF LC.  To help you decide to review, I've included a
>>     quick cut at the TSV topic needing attention (in brackets), but
>>     don't consider these hints to be comprehensive.
>>
>>     - draft-ietf-ccamp-ospf-availability-extension-06.txt
>>     [advertising link discrete variable bws]
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/tsv-art>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Sep 2016 14:35:35 -0700

Nevermind - found the appropriate WG for the capwap stuff.

Joe

On 9/26/2016 2:02 PM, Joe Touch wrote:
>> The comment about 6lo-dect-ule could be sent as a TSV ART early
>> review - we don't have a format for this (yet) but I think it's fine
>> to just use the TSV ART early review in subject line and ask them to
>> address the comment in their revisions prior to or during IETF LC.
>>     or incorrect (i.e., they violate requirements at the IP layer),
>>     as already noted in draft-intarea-tunnels. It would be useful for
>>     might be useful to consider IPsec TLS, and DTLS tunnels as well
>>     as those already listed.
>>
>>     ----
>>
>>     MTU:
>>
>>     draft-ietf-6lo-dect-ule-05.txt- Sec 2.4 indicates that the
>>     default MTU for DECT UL is 500 octets and does note that:
>>
>>        ...In order to
>>>     on you to volunteer, rather than trying to dispatch
>>>     assignments.  Perhaps seeing documents earlier will help you to
>>>     consistently offer 1-2 reviews per month to support Spencer and
>>>     Mirja.
>>>
>>>     In the document lists, if a date is present, it signifies the
>>>     end of the IETF LC.  To help you decide to review, I've included
>>>     a quick cut at the TSV topic needing attention (in brackets),
>>>     but don't consider these hints to be comprehensive.
>>>

---

From: Allison Mankin <[email-masked]>
Date: Mon, 26 Sep 2016 17:47:37 -0400

Hi, Joe:

Great that you found the WG for capwap.  Sure, send the one about finding
no issues too.  Again, thanks for the rapid response.

All:

We need two more rapid responders for the documents in Last Call, and then
takers for the early review items that are further down the list.   Feel
free to suggest someone else, or request a review from someone else, cc'ing
[email-masked]

David Black: B2BUA document that includes specific ECN handling?

Bernard Aboba: IPSECME DDoS avoidance?

-----------------
???  - draft-ietf-ipsecme-ddos-protection-09 [congestion/rate control] -
9/28
JOE - draft-ietf-opsawg-capwap-alt-tunnel-08 [tunneling] - 9/30
??? - draft-ietf-straw-b2bua-rtcp-13.txt [ECN] - 10/10
-----------------

P.S. The Triage team and ADs have agreed to do an update of the TSV-Art
Wiki soon

On 26 September 2016 at 17:02, Joe Touch <[email-masked]> wrote:

> ​

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Sep 2016 15:04:29 -0700

Yup - all three done.

Joe

On 9/26/2016 2:47 PM, Allison Mankin wrote:
> Hi, Joe: 
>
> Great that you found the WG for capwap.  Sure, send the one about
> finding no issues too.  Again, thanks for the rapid response.
>
> All:
>
> We need two more rapid responders for the documents in Last Call, and
> then takers for the early review items that are further down the list.
>   Feel free to suggest someone else, or request a review from someone
> else, cc'ing [email-masked] <mailto:[email-masked]>
>
> ???  - draft-ietf-ipsecme-ddos-protection-09[congestion/rate control]
> - 9/28
> P.S. The Triage team and ADs have agreed to do an update of the
> TSV-Art Wiki soon
>
>
>
>
> On 26 September 2016 at 17:02, Joe Touch <[email-masked]
>     <https://datatracker.ietf.org/wg/capwap/charter/>
>
>>
>>     review - we don't have a format for this (yet) but I think it's
>>     fine to just use the TSV ART early review in subject line and ask
>>     them to address the comment in their revisions prior to or during
>>     IETF LC.
>>         I'd like to provide some targeted feedback, if useful, on
>>         tunnel and MTU issues noted below, in light of the INTAREA
>>         tunnels document I've been working on.  I'm not sure any of
>>         these three documents needs more of a transport review than
>>         this. If useful, let me know and I can forward to each group
>>         separately.
>>
>>         Joe
>>
>>         ----
>>
>>         tunnel:
>>
>>         draft-ietf-opsawg-capwap-alt-tunnel-08 - this doc refers off
>>         to existing tunneling specifications, many of which are
>>         inconsistent or incorrect (i.e., they violate requirements at
>>         the IP layer), as already noted in draft-intarea-tunnels. It
>>         would be useful for this protocol to include signalling to
>>         indicate the receiver payload reassembly limit when
>>         indicating support for each tunnel type, to assist the source
>>         in determining whether the resulting tunnel will be IPv6
>>         compliant (rather than becoming a black hole for valid packet
>>         sizes). Additionally, for the transport protocol-based
>>         tunnels, it would be useful to indicate not only the endpoint
>>         IP address but the port number as well. Finally, it might be
>>         useful to consider IPsec TLS, and DTLS tunnels as well as
>>         those already listed.
>>
>>         ----
>>
>>         MTU:
>>
>>         draft-ietf-6lo-6lobac-05.txt - the protocol
>>         supports1280-1500B payloads without fragmentation and uses
>>         its own link header; as a result, this is sufficient for IPv6
>>         and there should be no new interaction with TCP or other
>>         transports.
>>
>>         ----
>>
>>
>>         referring to IPv6 only (as per the title of the doc), to
>>         indicate the minimum MTU, and to explain the reference to
>>         RFC4944:
>>
>>>         I reviewed all documents that are in IETF LC and LC
>>>         Requested as of 9/26.  I also looked at AD Review state as a
>>>         proxy for documents that recently passed through WGLC. 
>>>         Please find below all documents that I believe need TSV
>>>         review attention.  Your Action Needed is to volunteer to
>>>         The reason we've added some documents to get earlier reviews
>>>         to increase the regularity of reviews being asked of you in
>>>         the tsv-art (and, also, earlier review is good).  Currently
>>>         we count on you to volunteer, rather than trying to dispatch
>>>         assignments.  Perhaps seeing documents earlier will help you
>>>         to consistently offer 1-2 reviews per month to support
>>>         Spencer and Mirja.
>>>
>>>         expertise, but you are too busy, we'll be very happy for you
>>>         to identify and ask another person with your expertise to do
>>>         the review.  Just let us know by cc'ing [email-masked]
>>>         <mailto:[email-masked]>.  This will also help us to
>>>         expand the tsv-art.
>>>
>>>         In the document lists, if a date is present, it signifies
>>>         the end of the IETF LC.  To help you decide to review, I've
>>>         included a quick cut at the TSV topic needing attention (in
>>>         brackets), but don't consider these hints to be comprehensive.
>>>

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Sep 2016 22:36:18 +0000

> - draft-ietf-straw-b2bua-rtcp-13.txt [ECN] - 10/10

The ECN text in this draft basically says “see RFC 6679” - that’s fine for now, but some of the ECN experimentation work that’s likely to go forward soon may involve some modifications to RFC 6679 - I’m writing a short tsvwg draft on this in my “copious spare time” and have an email from Colin Perkins on text in RFC 6679 that’s likely to need
attention.

So, there’s nothing to do to draft-ietf-straw-b2bua-rtcp-13, but I probably should cite and reference it (plus look for other RFCs that refer to RFC 6679) in the forthcoming short draft on ECN experimentation.

Thanks, --David

From: Tsv-art [mailto:[email-masked]] On Behalf Of Allison Mankin
Sent: Monday, September 26, 2016 2:06 PM
To: [email-masked]
Cc: Allison Mankin
Subject: [Tsv-art] ACTION NEEDED: TSV reviewers for IETF LC/near-LC documents as of 9/26

Dear TSV ART-isans,
I reviewed all documents that are in IETF LC and LC Requested as of 9/26.  I also looked at AD Review state as a proxy for documents that recently passed through WGLC.  Please find below all documents that I believe need TSV review attention.  Your Action Needed is to volunteer to write a tsv-art review for one or more of these.
The reason we've added some documents to get earlier reviews to increase the regularity of reviews being asked of you in the tsv-art (and, also, earlier review is good).  Currently we count on you to volunteer, rather than trying to dispatch assignments.  Perhaps seeing documents earlier will help you to consistently offer 1-2 reviews per month to support Spencer and Mirja.
If you agree that a document needs review by someone of your expertise, but you are too busy, we'll be very happy for you to identify and ask another person with your expertise to do the review.  Just let us know by cc'ing [email-masked]<mailto:[email-masked]>.  This will also help us to expand the tsv-art.

In the document lists, if a date is present, it signifies the end of the IETF LC.  To help you decide to review, I've included a quick cut at the TSV topic needing attention (in brackets), but don't consider these hints to be comprehensive.
Documents that require TSV attention
Last Calls
- draft-ietf-ipsecme-ddos-protection-09 [congestion/rate control] - 9/28
- draft-ietf-opsawg-capwap-alt-tunnel-08 [tunneling] - 9/30
- draft-ietf-straw-b2bua-rtcp-13.txt [ECN] - 10/10
AD Review
- draft-ietf-6lo-6lobac-05.txt [MTU]
- draft-ietf-6lo-dect-ule-05.txt [MTU]
- draft-ietf-manet-credit-window-04 [receiver-based flow control over TCP?]
- draft-ietf-sidr-rpki-rtr-rfc6810-bis-07.txt [updated tsv requirements]

Documents that may require TSV attention
AD Review
- draft-ietf-6tisch-minimal-16.txt [link-level rxt]
- draft-ietf-ccamp-ospf-availability-extension-06.txt [advertising link discrete variable bws]
- draft-ietf-manet-dlep-24.txt [dynamic link exchange carried by TCP]
- draft-ietf-webpush-protocol-09.txt [https-level reliability to devices]

Documents that do not require TSV attention
Last Call
- draft-ietf-cose-msg-18

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Sep 2016 10:26:00 +0200

Hi,

I will do draft-ietf-webpush-protocol-09.

/Magnus

Den 2016-09-26 kl. 20:06, skrev Allison Mankin:
> than trying to dispatch assignments.  Perhaps seeing documents earlier
> will help you to consistently offer 1-2 reviews per month to support
> Spencer and Mirja.
>
> another person with your expertise to do the review.  Just let us know
> by cc'ing [email-masked] <mailto:[email-masked]>.  This will
> also help us to expand the tsv-art.
>
> TSV topic needing attention (in brackets), but don't consider these
> hints to be comprehensive.
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------