Re: [Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06

[Shumon Huque]

On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller <
linuxwolf+i...@outer-planes.net> wrote:

> Reviewer: Matthew Miller
> Review result: Ready with Nits
>
> 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: draft-ietf-tls-dnssec-chain-extension-06
> Reviewer: Matthew A. Miller
> Review Date: 2018-02-06
> IETF LC End Date: 2018-02-07
> IESG Telechat date: 2018-02-08
>
> Summary:
>
> This document is ready, with one issue that I think could benefit
> from some clarification.
>
> Major issues:
>
> NONE
>
> Minor issue:
>
> This is more a question, that might warrant some clarification:
> In 7. Verification, the last paragraph discusses client-side
> caching of the RRsets. If a client has cached the full RRset chain
> from TLSA to root RRSIG (and that cache is still viable), is the
> client still expected to specify the "dnssec_chain" extension?
>
> In my reading, that does not seem necessary, and I think it might
> be worth noting if that is true.
>

Yes, if the client has cached either the validated TLSA RRset or the
full chain, then it doesn't need to send the dnssec_chain for subsequent
connections.

If it has only cached other portions of the chain, then it needs to.

We can clarify this.

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

[Gen-art] Genart last call review of draft-ietf-modern-problem-framework-03

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready

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-modern-problem-framework-03
Reviewer: Joel Halpern
Review Date: 2018-02-06
IETF LC End Date: 2018-02-15
IESG Telechat date: 2018-02-22

Summary: This document is ready for publication as an Informational RFC.

Major issues:

Minor issues:
I presume that the lack of description on how to apply controls to
semi-restricted or restricted data, particulalry in the distributed data
store case, is deliberate?  I presume that the WG intent is that this is a
topic to be dealt with in the solutions, not the problem statement and
framework?  Things are fine if that is the intent.  If the WG views this as
an actual useful description of how to handle those aspects, then I would
ask for more descriptions.

Nits/editorial comments:
 Editorial: In the definition of Credential Authority the text uses the
 phrase "one of more" when I am pretty sure the intent is "one or more".


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

Re: [Gen-art] Genart telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-13

[Liyizhou]

Thanks Brian.

I will add " An IP address can be in either IPv4 or IPv6 format." to Section 
1.2 Target Scenarios as below.

Section 1.2 Target Scenarios
 In the Split-NVE architecture, the external NVE may be able to reach 
multiple MAC and IP addresses via a TSI. *An IP address can be in either IPv4 
or IPv6 format.* For example, .

Rgds,
Yizhou

-Original Message-
From: Brian Carpenter [mailto:brian.e.carpen...@gmail.com] 
Sent: Wednesday, February 07, 2018 6:32 AM
To: gen-art@ietf.org
Cc: n...@ietf.org; draft-ietf-nvo3-hpvr2nve-cp-req@ietf.org
Subject: Genart telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-13

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-pce-pcep-exp-codepoints-04

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-nvo3-hpvr2nve-cp-req-13.txt
Reviewer: Brian Carpenter
Review Date: 2018-02-07
IETF LC End Date: 2018-02-20
IESG Telechat date: 2018-02-22

Summary: Ready (with minor issue)


Comment:


This is a Last Call review despite the subject field.

Minor issue:


   Req-10: The protocol MUST allow an End Device initiating a request to
   add, remove or update address(es) associated with a TSI instance on
   the external NVE. Addresses can be expressed in different formats,
   for example, MAC, IP or pair of IP and MAC.

Here and elsewhere, it seems necessary to specify that an IP address can be in 
either IPv4 or IPv6 format. (This is implied in Table 1 and at the end of 
Appendix A, but that's quite well hidden.) I suggest clarifying this early, in 
Section 1.2 "Target Scenarios".

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

[Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06

[Matthew Miller]

Reviewer: Matthew Miller
Review result: Ready with Nits

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: draft-ietf-tls-dnssec-chain-extension-06
Reviewer: Matthew A. Miller
Review Date: 2018-02-06
IETF LC End Date: 2018-02-07
IESG Telechat date: 2018-02-08

Summary:

This document is ready, with one issue that I think could benefit
from some clarification.

Major issues:

NONE

Minor issue:

This is more a question, that might warrant some clarification:
In 7. Verification, the last paragraph discusses client-side
caching of the RRsets. If a client has cached the full RRset chain
from TLSA to root RRSIG (and that cache is still viable), is the
client still expected to specify the "dnssec_chain" extension?

In my reading, that does not seem necessary, and I think it might
be worth noting if that is true.

Nits/editorial comments: 

NONE

___
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-anima-voucher-05

[Toerless Eckert]

I am voting for "don't". (Is there a vote ?).

I can't find in 
https://datatracker.ietf.org/doc/review-ietf-anima-voucher-05-genart-lc-housley-2017-10-03/
anything suggesting that we should also describe support for XML in the 
document. Just the need to
complete the spec with the necessary signaling elements to support JSON. 

I think to remember we (authors) didn't only specify JSON to avoid documenting 
the
necessary signaling for XML, but also in an attempt to KISS, because
elements like registrars likely would need to implementations all options.

I also think we concluded that someone who strongly demanded XML would
be given the opportunity to do this in followup work, because that would
also give more time and opportunity to discuss/explain the insufficiency
of JSON for whatever folks want to use XML for in that followup work.
Similar logic to why we outsourced the voucher-request from the voucher
draft into BRSKI.

Cheers
Toerless

On Tue, Feb 06, 2018 at 04:53:14PM +, Kent Watsen wrote:
> Hi all,
> 
> Russ's comment led to the creation of an eContentType OID called
> id-ct-animaJSONVoucher.  Given that YANG modeled data can be 
> encoded in XML or JSON, I think that we made a mistake in only
> registering the JSON encoding.
> 
> FWIW, we originally choose to standardize on just JSON because
> we were trying to avoid the signaling complexity, exactly what
> this eContentType value provides.  It seems that, when we added
> the OID, we should've reexamined that earlier decision.
> 
> While I'd love to say that the fix is just a matter registering
> another OID, that draft uses the word "JSON" throughout, so a 
> slightly more involved edit would be needed.
> 
> Thoughts?  Is it too late?
> 
> Kent
> 
> 

-- 
---
t...@cs.fau.de

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

[Gen-art] Genart telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-13

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-pce-pcep-exp-codepoints-04

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-nvo3-hpvr2nve-cp-req-13.txt
Reviewer: Brian Carpenter
Review Date: 2018-02-07
IETF LC End Date: 2018-02-20
IESG Telechat date: 2018-02-22

Summary: Ready (with minor issue)


Comment:


This is a Last Call review despite the subject field.

Minor issue:


   Req-10: The protocol MUST allow an End Device initiating a request to
   add, remove or update address(es) associated with a TSI instance on
   the external NVE. Addresses can be expressed in different formats,
   for example, MAC, IP or pair of IP and MAC.

Here and elsewhere, it seems necessary to specify that an IP address
can be in either IPv4 or IPv6 format. (This is implied in Table 1
and at the end of Appendix A, but that's quite well hidden.)
I suggest clarifying this early, in Section 1.2 "Target Scenarios".

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

Re: [Gen-art] Genart telechat review of draft-ietf-idr-bgp-prefix-sid-11

[Alissa Cooper]

Peter, thanks for your reviews of this document. Acee, thanks for your 
responses. I have entered a No Objection ballot.

Alissa


> On Feb 2, 2018, at 8:14 AM, Acee Lindem (acee)  wrote:
> 
> Hi Peter, 
> 
> On 2/2/18, 1:47 AM, "Peter Yee" > 
> wrote:
> 
>Reviewer: Peter Yee
>Review result: Ready
> 
>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: draft-ietf-idr-bgp-prefix-sid-11
>Reviewer: Peter Yee
>Review Date: 2018-02-01
>IETF LC End Date: 2018-01-26
>IESG Telechat date: 2018-02-08
> 
>Summary:  This update incorporates most of the changes I noted for the -10
>draft and is ready for publication.
> 
>Major issues:
> 
>Minor issues:
> 
>Nits/editorial comments:
> 
>Okay, maybe spell my surname correctly. ;-)
> 
> This will be in the -11 version along with removal of the extra comma section 
> 1 ;^) 
> 
> Thanks,
> Acee 
> 
> 
> 
> ___
> 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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-bier-mvpn-09

[Alissa Cooper]

Meral, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Jan 26, 2018, at 6:37 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-bier-mvpn-09
> Reviewer: Meral Shirazipour
> Review Date: 2018-01-26
> IETF LC End Date: 2018-01-30
> IESG Telechat date: 2018-02-08
>  
>  
> Summary: This draft is ready to be published as Experimental RFC.
>  
> Major issues:
>  
> Minor issues:
>  
> Nits/editorial comments:
> -[Page 5], Sec 2, "may replaced">"may be replaced"
> -Section 9.1, ref [BIER_ARCH] is now RFC
>  
> 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 
> 
___
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-anima-voucher-05

[Kent Watsen]

Hi all,

Russ's comment led to the creation of an eContentType OID called
id-ct-animaJSONVoucher.  Given that YANG modeled data can be 
encoded in XML or JSON, I think that we made a mistake in only
registering the JSON encoding.

FWIW, we originally choose to standardize on just JSON because
we were trying to avoid the signaling complexity, exactly what
this eContentType value provides.  It seems that, when we added
the OID, we should've reexamined that earlier decision.

While I'd love to say that the fix is just a matter registering
another OID, that draft uses the word "JSON" throughout, so a 
slightly more involved edit would be needed.

Thoughts?  Is it too late?

Kent


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

Re: [Gen-art] [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06

[Weijun Wang]

I will submit a new draft tomorrow if there is no other feedback.

Thanks
Weijun

> On Jan 29, 2018, at 9:26 AM, Weijun Wang  wrote:
> 
> The HTML file updated in place.
> 
> Thanks
> Weijun
> 
>> On Jan 27, 2018, at 10:12 AM, Greg Hudson  wrote:
>> 
>> On 01/23/2018 06:43 PM, Weijun Wang wrote:
>>> I've uploaded an updated version at
>>> 
>>> http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html
>> 
>> This is a great format for reviewing these changes; thanks for
>> generating it.
>> 
>> Line 416 does not capitalize "optional" in "optional services", but
>> lines 385 and 391 do.
>> 
>> Lines 422 and 424 should probably capitalize "should".  Line 429 should
>> probably capitalize "may".
>> 
>> At line 598, I would lean towards leaving "MUST" in lowercase as we are
>> describing an application requirement, not prescribing one.
>> 
>> Line 1174, I would leave "MAY" in lowercase.
>> 
>> Line 1229, "may" should probably be capitalized.
>> 
>> Line 1369, I would leave "MAY" alone as this seems more descriptive than
>> prescriptive.
>> 
>> Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
>> request the default QOP.  So I would leave it lowercase (or change the
>> wording, but I'm not trying to open any more cans of worms).
>> 
> 
> ___
> Kitten mailing list
> kit...@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

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