Re: [Gen-art] Gen-ART Last Call review of draft-ietf-xrblock-rtcp-xr-video-lc-05

[Jari Arkko]

Thanks for the review!

On 10 Dec 2015, at 15:46, Alexey Melnikov  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-xrblock-rtcp-xr-video-lc-05
> Reviewer: Alexey Melnikov
> Review Date: 2015-12-10
> IETF LC End Date:  2015-12-04
> IESG Telechat date: 2015-12-17
> 
> 
> Summary:
> This draft is ready to be published as Standards Track RFC.
> 
> Although I am not en expert in RTCP, the Security Consideration section is 
> well thought through and looks complete to me.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-5966bis-05

[Jari Arkko]

Thank you, Brian!

On 01 Jan 2016, at 00:18, Brian E Carpenter  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 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-dnsop-5966bis-05.txt
> Reviewer: Brian Carpenter
> Review Date: 2016-01-01
> IETF LC End Date: 2015-12-07
> IESG Telechat date: 2016-01-07
> 
> Summary: Ready
> 
> 
> Comment: Thanks for fixing my Last Call comments
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-isis-prefix-attributes-04

[Jari Arkko]

Paul et al: Thanks for the review & the updates!

jari

On 05 Jan 2016, at 16:42, Paul Kyzivat  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 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 <​ 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-isis-prefix-attributes-04
> Reviewer: Paul Kyzivat
> Review Date: 2015-12-28
> IETF LC End Date: 2016-01-01
> IESG Telechat date: 2016-01-07
> 
> Summary:
> 
> The -04 version addressed my LC comments on the -03 version.
> 
> This draft is ready for publication as a Standards Track RFC.
> 
> Major: 0
> Minor: 0
> Nits: 0
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-isis-pcr-04

[Jari Arkko]

Thanks for the review, Suresh. I agree with your comment. Authors?

Jari

On 06 Jan 2016, at 06:32, Suresh Krishnan  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 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-isis-pcr-04.txt
> Reviewer: Suresh Krishnan
> Review Date: 2016-01-05
> Telechat Date: 2016-01-07
> 
> Summary: This draft is ready for publication as a Proposed Standard but I
> have a minor comment that you might wish to address.
> 
> * Minor
> 
> There is no reference for the format of the Bandwidth fields in Sections 6.3
> and 6.4. I am assuming this refers to the Single Precision format (binary32)
> from IEEE 754. If so, please add an explicit reference to this.
> 
> Thanks
> Suresh
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of

[Jari Arkko]

Thanks for your review, Ron!

On 16 Dec 2015, at 18:55, Ronald Bonica  wrote:

> Folks,
> 
> The authors of this draft have informed me this document is required by the 
> wg charter. So, I withdraw any criticisms about this document's limited 
> scope. The scope was dictated by the charter.
> 
>  Ron
> 
> 
>> -Original Message-
>> From: Ronald Bonica
>> Sent: Tuesday, December 15, 2015 4:01 PM
>> To: IETF Gen-ART ; 'draft-ietf-pals-congcons@ietf.org'
>> 
>> Subject: Gen-ART review of
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
>> ART, please see the FAQ at
>> 
>> 
>> Document:  draft-ietf-pals-congcons-01
>> Reviewer:Ron Bonica
>> Review Date:  2015-12-15
>> IETF LC End Date:  2015-12-15
>> IETF Telechat Date:  TBD
>> 
>> Summary:  This document is ready for publication
>> 
>> In summary, draft-ietf-congcons-01:
>> 
>> - applies only to pseudowires that run over something other than MPLS (e.g.,
>> GRE)
>> - concludes that no additional mechanisms are needed for elastic
>> pseudowires
>> - concludes that an inelastic pseudowire MAY shutdown when it experiences
>> higher-than-acceptable loss, latency or jitter
>> - observes that that for TDM PWs, as loss rate increases, higher-than-
>> acceptable loss generally occurs before the fixed-rate TDM PW could cause
>> serious problems for competing congestion-responsive traffic
>> - Therefore, no additional mechanisms are needed for inelastic pseudowires,
>> either
>> 
>> I see nothing objectionable in the draft. However, its scope is extremely
>> limited and it conclusions are not earthshattering. Nonetheless, the work is
>> sound and deserves publication.
>> 
>> Major Issues: None
>> 
>> Minor Issues: None
>> 
>> Editorial Issues:
>> 
>> Ron Bonica
>> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-josefsson-scrypt-kdf-03

[Jari Arkko]

Paul,

Many thanks for a careful reading. (This review raised questions that you could 
probably have sent to i...@ietf.org as well, as part of last call.)

And thanks Simon for addressing the questions Paul had!

With respect to the Information status, as explained this is indeed the IETF 
tradition. And non-Standards Track in general doesn’t mean that there is no 
spec to follow; it means that there’s no current IETF standard or 
recommendation in the area. So I think Informational is fine for this doc.

I think most of the other things were resolved, particularly the one about 
Integrity. I think the type mismatch is OK, but I had some other issues when 
reading through the spec, possibly confusions due to the notation and 
identifiers chosen. Will send a Discuss on those, hopefully you can answer or 
edit quickly and I can clear.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Minor nits in minorversion2-40

[Elwyn Davies]

Hi.

As suggested I downloaded your repository and made -40.

I had a quick look through and it is looking good.

Still to do/think about:
- 'we' removal
- structured privilege description expansion as per email.
- [BL73] - not reffed anymore.

I spotted a few items that appeared (or I had missed) - noted below.

Cheers,
Elwyn

Minor nits:
s4.2, para 2: s/intra-sever/intra-server/

s4.2.2, para 1: This sentence is a bit garbled:
Other operations are OPTIONAL in the context of a particular feature 
Section 13, but may become REQUIRED depending on server behavior.


s4.9, last para:
I was supposed to be letting you know if some extra explanation of why 
seqid being zero is ambiguous so, yes, I do think a bit extra is 
needed. Here goes:


s15.8.3 notes that there can be multiple file copies associated with a 
single file going on at the same time.  This is only implicit up to that 
point I think.  It would be helpful to add a note about this possibility 
and the availability of asynchronous copy in general to the intro of 
section 4.


BTW: removing the s4.1 header would be in keeping with usual style as 
you have already done for other sections.


BTW2:  I just realized that there is no general terminology section in 
this document.  Clearly most of it is taken over from either or both of 
RFC 7530 (s1.5) and RFC 5661 (s1.6).  What triggered this was the point 
that stateid isn't actually defined in this doc.  A reference to one or 
both of these and/or possibly some copies of definitions would be helpful.


In the following I may not have exactly grokked what the copy offload 
stateid represents... if so please adjust the words


Add to intro (was in s4.1, s/b in s4) as new last para:
ADD:
The copy feature allows the server to perform the copying either 
synchronously or asynchronously.  The client can request synchronous 
copying but the server may not be able to honor this request.  If the 
server intends to perform asynchronous copying, it supplies the client 
with a request identifier that  the client can use to monitor the 
progress of the copying and, if appropriate, cancel a request in 
progress.   The request identifier is a stateid representing the 
internal locks held by the server while the copying is performed. 
Multiple asynchronous copies of all or part of a file may be in progress 
in parallel on a server; the stateid request identifier allows 
monitoring and canceling to be applied to the correct request.

END

Then modify the last para of s4.9:
OLD:
   A copy offload stateid's seqid MUST NOT be zero.  In the context of a
   copy offload operation, it is ambiguous to indicate the most recent
   copy offload operation using a stateid with seqid of zero. Therefore
   a copy offload stateid with seqid of zero MUST be considered invalid.
NEW:
   A copy offload stateid's seqid MUST NOT be zero.  In the context of a
   copy offload operation, it is inappropriate to indicate "the most recent
   copy offload operation" using a stateid with seqid of zero (see 
Section 8.2.2

   of [RFC5661] for the meaning of a seqid of zero).  It is inappropriate
   because the stateid refers to internal state in the server and there 
may

   be several asynchronous copy operations being performed in parallel
   on the same file by the server.  Therefore
   a copy offload stateid with seqid of zero MUST be considered invalid.
END

s4.10, last para:
OLD:
   If a server requires the use of RPCSEC_GSSv3 copy_to_auth,
   copy_from_auth, or copy_confirm_auth and it is not used, the server
   will reject the request with NFS4ERR_PARTNER_NO_AUTH.

NEW:
   If a server requires the use of an RPCSEC_GSSv3 copy_to_auth,
   copy_from_auth, or copy_confirm_auth privilege and it is not used, 
the server

   will reject the request with NFS4ERR_PARTNER_NO_AUTH.

s4.10.1.1.1:  I understood you were going to say something about size 
and non-reuse of the random number?


s4.10.1.1.3, bullet 6: s/the COPY will be rejeced/the COPY will be rejected/

s8:  Did you think about 64bit big-endian/little-endian issues?

s9.2, last para: Need to expand LFS on first use. (missed in -39)

s10.5.6, para 2: (Not a change - I missed this in -39)
Any file's layout obtained from a NFSv4.1 metadata server MUST NOT 
have NFL42_UFLG_IO_ADVISE_THRU_MDS set.
I don't understand this statement.  If the layout is originated by an 
NFSv4.1 server, then I would interpret having this bit set as a server bug.


s12.1: One of the ADs complained about the weasel words in the Id column 
definition... the slightly less weaselly words from s5.6 of RFC7530 
should cure this.


s19.2:  Need to sort out [BL73].

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

[Gen-art] Gen-ART LC Review of draft-ietf-hip-rfc6253-bis-06

[Romascanu, Dan (Dan)]

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



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 

 >.



Document: draft-ietf-hip-rfc6253-bis-06

Reviewer: Dan Romascanu

Review Date: 1/7/2016

IETF LC End Date: 12/28/2015

IESG Telechat date:



Summary: On the right track



The document is well structured, but there are a number of issues that must be 
fixed before it is approved by the IESG.



Major issues:



1.   The Type number values mentioned in Section 2 (after the certificate 
types table) refer to the values in RFC 6253 (that go to 8) and not in the 
values in this document.

2.   The IANA Considerations section needs in my opinion to be re-written. 
RFC 6263 was an Experimental RFC, this document has an Intended Status of 
Standards Track, it cannot just refer to the content of the document that it is 
obsoleting.

3.   A new Certificate type registry needs to be defined in my opinion. 
Older values in the registry were 0 to 8, this document should not use values 
of 0 to 4 in the same registry while some of the values have different 
semantics.



Minor issues:



1.   The front page does not provide the initials of the first name of the 
authors. This may seem a nit, but there may be tools that are used with 
processing the initials of the authors name.

2.   Inconsistent use of CERT (the parameter in RFC 7401) and Cert (as in 
Cert group, Cert count, etc.). Any special reason not to write consistently 
CERT every place?

3.   I am missing a section that would remain in the document (unlike 
Appendix B which I suspect will be taken out at publication) and that shortly 
lists the changes from RFC 6253 and their motivation.



Nits/editorial comments:



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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-hip-rfc6253-bis-06

[Terry Manderson]

Dan,

Thank you for your review.

hip-rfc6253-bis authors and shepherd,

There are some concerning aspects to Dan's review. Given that Dan
recommends a new Certificate type registry "item 3", I'm thinking of
passing this document back to the WG to consider this along with a
constructing a new IANA considerations section.

Is there any reason, in your opinion that this (send back to the WG)
should not be the next action?

Cheers
Terry


On 8/01/2016 2:53 am, "Romascanu, Dan (Dan)"  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
> 
><
>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
>rea_gen_trac_wiki_GenArtfaq=BQICAg=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31O
>cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=I5w-zqhErChUOoLzPbfnc5q4QAnQBWAJUImX_o
>cF2PI=G5nNtC3MnxOIveGWM1XBHjDn3cEV_Kl-HTkJ9jXPp00=%20>>.
> 
>Document: draft-ietf-hip-rfc6253-bis-06
>Reviewer: Dan Romascanu
>Review Date: 1/7/2016
>IETF LC End Date: 12/28/2015
>IESG Telechat date:
> 
>Summary: On the right track
> 
>The document is well structured, but there are a number of issues that
>must be fixed before it is approved by the IESG.
>
> 
>Major issues:
> 
>1.  
>The Type number values mentioned in Section 2 (after the certificate
>types table) refer to the values in RFC 6253 (that go to 8) and not in
>the values in this document.
>2.  
>The IANA Considerations section needs in my opinion to be re-written. RFC
>6263 was an Experimental RFC, this document has an Intended Status of
>Standards Track, it cannot just refer to the content of the document
> that it is obsoleting.
>3.  
>A new Certificate type registry needs to be defined in my opinion. Older
>values in the registry were 0 to 8, this document should not use values
>of 0 to 4 in the same registry while some of the values have different
> semantics.
> 
>Minor issues:
> 
>1.  
>The front page does not provide the initials of the first name of the
>authors. This may seem a nit, but there may be tools that are used with
>processing the initials of the authors name.
>
>2.  
>Inconsistent use of CERT (the parameter in RFC 7401) and Cert (as in Cert
>group, Cert count, etc.). Any special reason not to write consistently
>CERT every place?
>
>3.  
>I am missing a section that would remain in the document (unlike Appendix
>B which I suspect will be taken out at publication) and that shortly
>lists the changes from RFC 6253 and their motivation.
>
> 
>Nits/editorial comments:
> 
> 
>


smime.p7s
Description: S/MIME cryptographic signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-edns-tcp-keepalive-04

[Jari Arkko]

Thanks.

On 07 Jan 2016, at 21:08, Brian E Carpenter  wrote:

> Just confirming, as the IESG dealt with this while I was sleeping:
> 
> Yes, everything looks fine in the -05 draft.
> 
> Thanks
>   Brian
> 
> On 08/01/2016 01:39, Jari Arkko wrote:
>> Many thanks again for the review. My read of the new version indicates that 
>> the issues have been resolved. Let me know otherwise.
>> 
>> Jari
>> 
>> On 01 Jan 2016, at 00:11, Brian E Carpenter  
>> wrote:
>> 
>>> Still "Ready with issues" pending a new version.
>>> 
>>> Regards
>>>  Brian
>>> 
>>> On 24/11/2015 04:03, Tim Wicinski wrote:
 Brian
 
 Thanks for the review - comments in line.
 
 On 11/22/15 8:58 PM, Brian E Carpenter 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-dnsop-edns-tcp-keepalive-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2015-11-23
> IETF LC End Date: 2015-11-30
> IESG Telechat date:
> 
> Summary: Ready with issues
> 
> 
> Comment: These are only standards-language issues, nothing fundamental.
> 
> 
> Major Issues:
> -
> 
> Last paragraph of section 3.2.2.  Receiving Responses:
> 
>   A DNS client that sent a query containing the edns-keepalive-option
>   but receives a response that does not contain the edns-keepalive-
>   option should assume the server does not support keepalive and behave
>   following the guidance in [DRAFT-5966bis].  This holds true even if a
>   previous edns-keepalive-option exchange occurred on the existing TCP
>   connection.
> 
> Firstly, shouldn't that "should" be a SHOULD?
 
 Yes, that should be a SHOULD.  Good catch
 
> 
> More important, [DRAFT-5966bis] really looks like a normative reference 
> to me.
> I couldn't code this without reading that reference. It's already entering
> Last Call so hopefully this won't waste much time.
 
 That's interesting. I think we decided to make it informative is that its 
 covering new discussions.
 
> 
> Section 3.6.  Anycast Considerations:
> 
>   ...
>   Changes in network topology between clients and anycast servers may
>   cause disruption to TCP sessions making use of edns-tcp-keepalive
>   more often than with TCP sessions that omit it, since the TCP
>   sessions are expected to be longer-lived.  Anycast servers MAY make
>   use of TCP multipath [RFC6824] to anchor the server side of the TCP
>   connection to an unambiguously-unicast address in order to avoid
>   disruption due to topology changes.
> 
> IMHO, [RFC6824] is another normative reference; and it's a downref since
> it's an Experimental RFC. I think you could avoid this by weakening
> the last sentence a bit:
> 
>   It might be possible for anycast servers to avoid disruption due to
>   topology changes by making use of TCP multipath [RFC6824] to anchor
>   the server side of the TCP connection to an unambiguously unicast 
> address.
> 
 
 That's a useful edit. I'll circle back to the authors on this.
 
 thanks again
 
 tim
 
>>> 
>>> ___
>>> Gen-art mailing list
>>> Gen-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art