[Gen-art] Genart last call review of draft-ietf-dnssd-push-20

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Issues

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: draft-ietf-dnssd-push-20
Reviewer: Robert Sparks
Review Date: 2019-06-28
IETF LC End Date: 2019-07-05
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard but with an Issue to
consider before publication,

Issue:

The discussion of recursive resolvers in section 6.1 may need additional
consideration. In particular, the recommendation to pass a received error code
along to a client has, I think, some unintended consequences for the client. If
the recursive server receives a NOTIMP, for example, passing that to the client
tells the client the wrong thing about the server it is connected to. Perhaps
it would be better for the recursive server to return SERVFAIL in this
circumstance? (Similar to what it would do if it couldn't connect to the next
server as described at the bottom of page 10).

Nits:

Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a
2119/8174 keyword. I suggest using lowercase 'not required' in this sentence.

Page 7, Section 4, 3rd paragraph: The first sentence alludes to concerns about
anonymous subscriptions, saying TCP alleviates those concerns. As written this
is pretty vague. Can you expand on what you mean by an anonymous subscription
in this context?

Page 10, Section 6.1, first sentence: Suggest s/first step in DNS Push/first
step in a DNS Push/

Page 15, last paragraph: Why MUST the server immediately terminate a connection
in this situation? Just accepting the request seems safe - having subscription
requests show up for the same name seems nearly idempotent, and only one PUSH
would result from having multiple such subscriptions. Is this close an attempt
to avoid resource denial attacks buy some node subscribing many times to the
same thing? That feels extreme, especially since tearing down the connection
would cancel other subscriptions the client already has established on that
connection.

Page 16, second paragraph: I suggest replacing the second sentence with
something like "A name in a SUBSCRIBE message that matches only a literal CNAME
in the zone will only receive notifications of changes to the CNAME (assuming
the subscription asks for that type), and nothing else."

Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP,
the "(or equivalent for other protocols)" phrase should be removed.


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

[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

Last calls:

Reviewer   Type  LC end Draft
Jari Arkko Last Call 2019-06-19 draft-ietf-mmusic-sdp-uks-05
Jari Arkko Last Call 2019-06-04 
draft-ietf-anima-bootstrapping-keyinfra-22 *
Francis Dupont Last Call 2019-07-08 draft-ietf-i2nsf-applicability-13
Francis Dupont Last Call 2019-06-26 draft-ietf-6tisch-architecture-23
Roni Even  Last Call 2019-07-11 draft-ietf-ospf-xaf-te-06
Pete Resnick   Last Call 2019-07-04 draft-ietf-intarea-frag-fragile-13
Meral Shirazipour  Last Call 2019-06-28 draft-ietf-v6ops-nat64-deployment-06
Robert Sparks  Last Call 2019-07-05 draft-ietf-dnssd-push-20

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Francesca Palombini
  Pete Resnick
  Ines Robles
  Dan Romascanu

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] [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10

[Russ Housley]

Juliusz:

> Thank you very much for your review.  I agree with all of your comments
> save one, I'll publish a new revision taking your comments into account as
> soon as possible.
> 
>>   ...  A node SHOULD NOT send triggered updates
>>   for other reasons, such as when there is a minor fluctuation in a
>>   route's metric, when the selected next hop changes, or to propagate a
>>   new sequence number (except to satisfy a request, as specified in
>>   Section 3.8).
> 
>> This seem backwards to me.  Perhaps:
> 
>>   ...  The node MUST send triggered updates to satisfy a request, as
>>   specified in Section 3.8; however, a node SHOULD NOT send
>>   triggered updates for other reasons, including a minor fluctuation
>>   in a metric for a route, the selected next hop changes, or to
>>   propagate a new sequence number.
> 
> I disagree.  The requirement to send triggered updates is already present
> in 3.8.1.1, we should not repeat it.  This section is concerned with
> avoiding excessive noise.

I defer to your experience.

Russ

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-v6ops-nat64-deployment-06

[Fred Baker]

Thanks much. I’m glad you approve :-)

Sent using a machine that autocorrects in interesting ways...

> On Jun 27, 2019, at 5:42 PM, Meral Shirazipour 
>  wrote:
> 
> 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: draft-ietf-v6ops-nat64-deployment-06
>  
> Reviewer: Meral Shirazipour
> Review Date: 2019-06-27
> IETF LC End Date: 2019-06-28
> IESG Telechat date: NA
>  
>  
> Summary: This draft is ready to be published as Informational RFC .
>  
>  
> Major issues:
>  
> Minor issues:
>  
> Nits/editorial comments:
>  
>  
>  
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson Research
> www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art