[Gen-art] Genart last call review of draft-ietf-cbor-array-tags-07

[Elwyn Davies via Datatracker]

Reviewer: Elwyn Davies
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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-cbor-array-tags-07
Reviewer: Elwyn Davies
Review Date: 2019-09-06
IETF LC End Date: 2019-09-05
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with a couple of nits.  Apologies for slightly late delivery.

Major issues:
None

Minor issues:
None

Nits/editorial comments:
s1, para 2: s/have received/has received/

s1, para 3: s/This also can/This can also/

s1.1, last para: s/whether that/as to whether that/

s2.1, 2nd para after Table 2 (top of page 5):
OLD:
     It can be computed
     inversely to the previous formula from the length of the byte string
     in bytes: "bytelength >> (f + ll)".
NEW:
     It can be computed from the length of the byte string comprising the
     representation of the array by inverting the previous formula: "bytelength
 >> (f + ll)".
ENDS

s2.1: The terms endianness, big endian and litle endian are jargon, if pretty
well known jargon, but I don't know if they are considered to be adequately
well understood to avoid the need for a reference or  an explanation of what is
meant.


___
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-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thank you for your comments Stewart, please see my responses below. A new 
version of the draft will be published shortly and will address all of the 
review comments that needed edits.





Thanks

Roger



-Original Message-

From: Stewart Bryant via Datatracker mailto:nore...@ietf.org>>

Sent: Thursday, June 27, 2019 8:57 AM

To: gen-art@ietf.org

Cc: i...@ietf.org; 
draft-ietf-regext-epp-fees@ietf.org;
 reg...@ietf.org

Subject: Genart last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Reviewer: Stewart Bryant

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-regext-epp-fees-16

Reviewer: Stewart Bryant

Review Date: 2019-06-27

IETF LC End Date: 2019-07-08

IESG Telechat date: Not scheduled for a telechat



Summary:



A well written document that is ready for publication subject to a couple of 
clarifications



Major issues: None



Minor issues:



===

2.  Migrating to Newer Versions of This Extension



   (Note to RFC Editor: remove this section before publication as an

   RFC.)



SB> This seems like good advice, why is it to be removed?



[RDC] Agree, Note has been removed

===



   Copyright (c) 2018 IETF Trust and the persons identified as authors

   of the code.  All rights reserved.



   Redistribution and use in source and binary forms, with or without

   modification, are permitted provided that the following conditions

   are met:



   o  Redistributions of source code must retain the above copyright

  notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright

  notice, this list of conditions and the following disclaimer in

  the documentation and/or other materials provided with the

  distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the

  names of specific contributors, may be used to endorse or promote



SB> It is not clear what the purpose of this text is, whether or not it

SB>is  intended to be included with each instance the technical text below.

SB>If not why is the copyright not covered by the RFC boilerplate copyright 
text?



[RDC] This verbiage has been removed.



=

7.  Security Considerations



   The mapping extensions described in this document do not provide any

   security services beyond those described by EPP [RFC5730], the EPP

SB> "security services" or "security risks"



[RDC] “security services”

=



Nits/editorial comments: None




___
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:

For telechat 2019-09-19

Reviewer   Type  LC end Draft
Pete Resnick   Telechat  2019-09-17 draft-ietf-cbor-sequence-01

Last calls:

Reviewer   Type  LC end Draft
Elwyn Davies   Last Call 2019-09-05 draft-ietf-cbor-array-tags-07
Roni Even  Last Call 2019-09-12 draft-ietf-sipcore-digest-scheme-08
Wassim Haddad  Last Call 2019-09-13 
draft-ietf-teas-native-ip-scenarios-08
Joel Halpern   Last Call 2019-09-14 draft-ietf-sipcore-callinfo-spam-04
Suhas Nandakumar   Last Call 2019-09-17 draft-ietf-stir-oob-05
Meral Shirazipour  Last Call 2019-09-18 draft-ietf-dnsop-obsolete-dlv-00

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Robert Sparks
  Dale Worley
  Peter Yee
  Jari Arkko
  Stewart Bryant
  Brian Carpenter
  Elwyn Davies
  Linda Dunbar
  Francis Dupont
  Theresa Enghardt

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-pce-lsp-control-request-08

[Dhruv Dhody]

Hi Francesca,

Thanks for your review. Few thoughts...

On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker
 wrote:
>
> Reviewer: Francesca Palombini
> 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-pce-lsp-control-request-08
> Reviewer: Francesca Palombini
> Review Date: 2019-08-26
> IETF LC End Date: 2019-08-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is almost ready for publication, but has minor issues/open
> points that should be fixed before publication.
>
> Major issues: N/A
>
> Minor issues / questions:
>
> * Section 3: At the end of season 3, you indicate that this new flag has no
> meaning in PCRpt and PCInitiate messages. RFC8231 defines that the SRP Object
> MAY be carried in PCErr as well, shouldn't there be such requirements (MUST be
> set to 0, MUST be ignored on reception) for PCErr?
>

I agree. I suggest to make this generic, something like - "The C Flag
has no meaning in other PCEP messages that carry SRP object and the
flag MUST be set to 0 on transmission and MUST be ignored on receipt."

> * In the following text (Section 4): "The PCE SHOULD NOT
>send control request for LSP which is already delegated to the PCE,
>i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
>NOT be set." Why is there a SHOULD NOT instead of MUST NOT? In which
>situation could it be acceptable or useful to request control for a
>delegated LSP?
>

It wont be useful, but if received it would be silently ignored. It
does not rise up to a high level of error and I suspect that is why
authors used SHOULD.

> Nits/editorial comments:
>

Thanks for these, just one comment ...

> * Terminology should also include a sentence about the reader being familiar
> with at least RFC8231.
>
> * Terminology could also include what SRP stand for.
>
> * Section 3. When introducing SRP, it would have been helpful to the reader to
> reference section 7.2 of RFC8231.
>
> * Section 3. "PCE sets the C Flag to 1 to indicate that, it wishes" -- remove
> ","
>
> * Section 3. "MUST be ignored on receipt" -- "MUST be ignored on reception"
>

I have noticed 'on receipt' in many of our documents. We should leave
this one for the RFC-EDITOR maybe...

> * Section 4. When introducing the D flag, it would have been helpful to the
> reader to reference section 7.3 of RFC8231.
>
> * Section 4. "Note that, the PCUpd message with C Flag set is received" --
> "Note that, if the PCUpd message with C Flag set is received"
>
> (Please keep my address in the To: field if you want to make sure I see any
> response to this thread)
>
> Thanks,
> Francesca
>

Thanks again for your review.

Regards,
Dhruv

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