[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

For telechat 2019-08-08

Reviewer   Type  LC end Draft
Jari Arkko Last Call 2019-06-19 draft-ietf-mmusic-sdp-uks-06
Linda Dunbar   Telechat  2019-01-04 
draft-ietf-curdle-ssh-ed25519-ed448-09 *
Robert Sparks  Telechat  2019-07-05 draft-ietf-dnssd-push-23 *

For telechat 2019-08-22

Reviewer   Type  LC end Draft
Pete Resnick   Last Call 2019-08-15 
draft-ietf-opsec-urpf-improvements-03

Last calls:

Reviewer   Type  LC end Draft
Stewart Bryant Last Call 2019-08-15 
draft-ietf-manet-dlep-lid-extension-05
Elwyn Davies   Last Call 2019-08-14 draft-ietf-iasa2-rfc5377bis-02
Linda Dunbar   Last Call 2019-08-07 
draft-ietf-oauth-jwt-introspection-response-05
Francis Dupont Last Call 2019-08-12 draft-ietf-tls-grease-03
Roni Even  Last Call 2019-08-13 draft-ietf-netmod-artwork-folding-07
Joel Halpern   Last Call 2019-08-12 draft-ietf-rmcat-nada-11
Pete Resnick   Last Call 2019-07-19 
draft-ietf-lpwan-ipv6-static-context-hc-21
Meral Shirazipour  Last Call 2019-08-01 draft-ietf-acme-star-06
Meral Shirazipour  Last Call 2019-08-01 draft-ietf-oauth-mtls-15
Peter Yee  Last Call 2019-08-05 draft-ietf-iasa2-rfc2031bis-05

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Roni Even
  Tim Evens
  Fernando Gont
  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End LC Template --

-- Begin Telechat Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

[Alissa Cooper]

Jen, thanks for the updates. Pete, thanks for your response. I cleared my 
DISCUSS.

Cheers,
Alissa

> On Jul 3, 2019, at 10:58 PM, Pete Resnick  wrote:
> 
> Hi Jen,
> 
> Thanks for the additional updates. A few comments inline.
> 
> On 3 Jul 2019, at 20:07, Jen Linkova wrote:
> 
>>> Again, hosts pick default addresses for applications to use, and
>>> applications pick the addresses that packets will use.
>> 
>> OK, I guess we are just using different terminology here...
>> For me 'a host' is a whole element connected to the network, including
>> all subsystems and applications running.
>> Until your email I was thinking about an application as an element of
>> a host. If I got you right, when the draft says 'host' you read it as
>> 'network stack on a host', right?
> 
> Well, yes, to a certain extent. But my point here was a bit different: Even 
> if we call it "the network stack on a host", it isn't picking the addresses 
> that packets will use, at least not on a packet-by-packet basis. That gets 
> back to the point about dynamic updates: Even if the host stack were to 
> change its mind about which the correct address is, that host isn't using 
> that new address for packets unless/until currently running apps shut down 
> their existing connections and make new ones. They're using the old address 
> until doing so actually fails, and then only if they reinitiate 
> communications. The "stack" can't change that, it can only suggest to the 
> upper layers that they stop using what they're currently using. (You've 
> talked about this in the new paragraph in 6.)
> 
>>> How about this? :
>>> 
>>> "It should be noted that [RFC6724] only defines the behavior of IPv6
>>> hosts to select default addresses that applications and upper-layer
>>> protocols can use. Applications and upper-layer protocols can make their
>>> own choices on selecting source addresses. The mechanism proposed in
>>> this document attempts to..."
>> 
>> I've updated that paragraph:
>> 
>> "It should be noted that [RFC6724] only defines the behavior of IPv6
>> hosts to select default addresses that applications and upper-layer
>> protocols can use. Applications and upper-layer protocols can make
>> their own choices on selecting source addresses. The mechanism
>> proposed in this document attempts to ensure that the subset of source
>> addresses available for applications and upper-layer protocols is
>> selected with the up-to-date network state in mind. The rest of the
>> document discusses various aspects of the default source address
>> selection defined in [RFC6724], calling it for the sake of brevity
>> "the source address selection".
>> 
>> I hope that the last sentence makes the rest of the document less confusing.
>> What do you think?
> 
> Yes, that'll be OK.
> 
>>> I'd also suggest taking a look through the rest of section 6 for use of
>>> the word "host" and see if the word "default" needs to be inserted
>>> somewhere after it (like "...hosts to choose the correct *default*
>>> source address"), or if it needs to be changed to "application".
>> 
>> I've updated a number of places as well.
> 
> There are still quite a few places that I would change in section 6, but I'll 
> leave it to Alissa to decide which (if any) are really worth diving into. I 
> think now you understand what I'm trying to get at.
> 
>>> Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as
>>> another mechanism (in addition to BGP) to deal with the problem.
>> 
>> It is there:
>> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3
> 
> Sorry, I wasn't clear: I meant it would be nice if there reference in 6.7.1 
> to section 8.3, or a mention in 6.7.1 of MPTCP in addition to its mention of 
> BGP.
> 
> My suspicion is that section 7.3 underestimates the availability
> (current and
> future) of multipath transport.
>> 
>>> You can have the half empty glass; I'll take the half full one. ;-)
>> 
>> As per Magnus's suggestion, I've updated the text to mention that
>> PA-based multihoming and MP transport could benefit from each other:
>> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3
> 
> Fair enough.
> 
> Thanks again for the updates. As the boilerplate for the review says, wait 
> for instructions from your AD for further guidance, particularly in order to 
> address Alissa's DISCUSS.
> 
> pr
> -- 
> Pete Resnick http://www.episteme.net/
> All connections to the world are tenuous at best
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art