Re: [Gen-art] Genart last call review of draft-ietf-cdni-additional-footprint-types-04

[Nir Sopher]

Thanks David for reviewing the document :)
Cheers,
Sanjay and Nir

On Thu, Dec 1, 2022 at 6:16 PM David Schinazi via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: David Schinazi
> 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-cdni-additional-footprint-types-04
> Reviewer: David Schinazi
> Review Date: 2022-12-01
> IETF LC End Date: 2022-12-09
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Clear draft that explains why it requests IANA allocations.
>
> Major issues: none
>
> Minor issues: none
>
> Nits/editorial comments: none
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Manycouches] Genart last call review of draft-ietf-shmoo-online-meeting-04

[Mirja Kuehlewind]

Hi Dale!

Thanks! See quickly below!

Mirja

> On 6. Dec 2022, at 22:02, Dale Worley via Datatracker  
> wrote:
> 
> Reviewer: Dale Worley
> 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-shmoo-online-meeting-04
> Reviewer:  Dale R. Worley
> Review Date:  2022-12-06
> IETF LC End Date:  2022-12-13
> IESG Telechat date:  [unknown]
> 
> Summary:
> 
>This draft is ready for publication as an informational RFC, with
>the possible exception of the possible nits listed below.
> 
> Nits/editorial comments:
> 
> 2.  Some History
> 
>   participants later indicated in mailing discussion that the period of
> 
> "mailing discussion" is an unusual phrase.  Perhaps "mail discussion"
> was intended?
> 
>   intensive interims had a greater impact on their calendar than a
>   single plenary meeting week, and in some meeting.
> 
> The final "in some meeting" seems to be incomplete and (given the
> context) may be omitting something important.

Yes, we messed something up here in the last revision.

Already fixed here: 
https://github.com/mirjak/draft-shmoo-online-meeting/pull/24/files 


> 
> 3.3.  Session/Break Length
> 
>   The longer breaks, while extending the day, provided adequate time
>   for "hallway" conversations using online tools, exercise, and meals.
> 
> Probably would be clearer as "... adequate time for meals, exercise,
> and "hallway" conversations using online tools."

Done.

> 
> 4.1.  Full vs. limited agenda (and interim meetings)
> 
> This section heading and the one for section 4.2 are capitalized
> differently from the rest.  But I expect the Editor will deal with
> that.

Done.

> 
> 4.2.  Flexibility of time usage
> 
>   Hackathon for fully online only meetings is usually held in the week
> 
> "fully online only" has two modifiers with the same meaning.

Right, we changed that at some point and now use fully online instead online 
only; I guess the only was an oversight of that change.

> 
> 4.4.  Experiments
> 
>   Furthermore, the IESG SHOULD announce any such experiment in advance,
>   so people can adjust to changes and potentially provide feedback.
> 
> I would intensify this as "announce ... well in advance".

Done.

Also changes here: 
https://github.com/mirjak/draft-shmoo-online-meeting/pull/26/files 


> 
> 6.2.  Informative References
> 
>   [_107-FEEDBACK]
> 
> I see that there are a number of references with citation tags that
> have this unusual format.  Verify this is the intended format rather
> than a formatting malfunction.

Yes, not sure why this is. I hope the RPC can fix that…


> 
> [END]
> 
> 
> 
> ___
> Manycouches mailing list
> manycouc...@ietf.org
> https://www.ietf.org/mailman/listinfo/manycouches
> 

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

[Gen-art] Resending: Gen-art last call review of draft-moskowitz-ipsecme-ipseckey-eddsa-06

[Behcet Sarikaya]

Hi all,

I am satisfied with the responses by the author to my review completely.
So I change my review

Document:draft-moskowitz-ipsecme-ipseckey-eddsa-06
Reviewer: Behcet Sarikaya
Review Date: 2022-11-28
IETF LC End Date:2022-12-12
IESG Telechat date: (if known)

Summary: Ready to go.

Major issues:
None

Minor issues:
None

Nits/editorial comments: None



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

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Lars Eggert]

Joel, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Jun 28, 2022, at 23:09, Joel Halpern via Datatracker  
> wrote:
> 
> Reviewer: Joel Halpern
> 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-ippm-ioam-ipv6-options-08
> Reviewer: Joel Halpern
> Review Date: 2022-06-28
> IETF LC End Date: 2022-07-01
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: If the issues identified below are addressed, this document will be
> ready for publication as a Proposed Standard RFC.
> 
> Major issues:
>Why is the domain boundary expectation in section 4 only a SHOULD?  Either
>there is no need to restrict it, or it is important and it is a MUST?  This
>comes up again in section 5.1 item C4.
> 
> Minor issues:
>The document uses the term IOAM extensively.  It expands the term as
>"In-situ Operations, Administration, and Maintenance".  While a good start,
>it would be very helpful if the document either defined IOAM or cited a
>definition.  The expansion does not explain what the difference is between
>IOAM and other forms of OAM, nor indicate what sorts of packets IOAM
>applies to.
> 
>Section 5.1 (Considerations for IOAM deployment in IPv6 networks)
>requirement C1 seems to be an implementation requirement not a deployment
>requirement.  The text even ends with "Implementations of IOAM SHOULD..."
>Why is this in a deployment considerations section?
> 
>Requirement C3 in section 5.1 is very oddly worded.  It seems to say "X
>should not happen" but does not tell the implementor or deployer how to
>avoid having X occur.  I would recommend rewording.  (At a guess, something
>about how entities sending errors outside of an IOAM domain should remove
>any IOAM data??)
> 
>Requirement C5 in 5.1 says that leaks need to be easily identified and
>attributed.  That's nice.  It doesn't seem to say HOW that is to be done.
>So how does an implementor or deployer comply with the requirement?
> 
> Could the description clause of the two IANA entries please use "IOAM
> destination option" and "IOAM hop-by-hop option" rather than describing
> them both just as "IOAM".
> 
> Nits/editorial comments:
>Given the problems of acronym overload and the sparse need for it, I would
>recommend not using the acronym ION (IOAM Overlay Network), and simply
>spelling that out in the few places it is needed.
> 
>It would be helpful if section 5.3 (IOAM domains bounded by network
>devices) restated that such ingress edge devices will encapsulate the user
>packet, and put the IOAM option in the resulting encapsulating header.  And
>decapsulate at the egress.
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
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-lamps-rfc3709bis-06

[Lars Eggert]

Paul, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On Oct 25, 2022, at 17:54, 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-lamps-rfc3709bis-06
> Reviewer: Paul Kyzivat
> Review Date: 2022-10-25
> IETF LC End Date: 2022-10-28
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> Issues:
> 
> Major: 0
> Minor: 1
> Nits:  2
> 
> 1) MINOR: In Section 4.1 (Extension Format):
> 
> The following:
> 
> "CAs SHOULD use the one-way hash function that is associated with the 
> certificate signature to compute the hash value, and CAs MAY include other 
> hash values."
> 
> introduces the possibility that a client might not support *any* of the 
> provided hash algorithms. This seems bad.
> 
> RFC3709 didn't have this problem because it required that an SHA-1 hash be 
> included and supported.
> 
> This can be fixed by changing "CAs SHOULD" to "CAs MUST".
> 
> 2) NIT: From IdNits:
> 
> ** Downref: Normative reference to an Informational RFC: RFC 1952
> 
> I think it would be ok to change the reference to Informative.
> 
> 3) NIT: Typos
> 
> In Section 3 (Logotype Data):
> 
> s/then each image objects/then each image object/
> 
> In Section 7 (Image Formats):
> 
> s/The following table lists many commons/The following table lists many 
> common/
> 
> s/requirements these image formats/requirements for these image formats/
> 
> s/the client will receive response/the client will receive a response/
> 
> (The last one above appears twice.)
> 
> In Section 10 (Privacy Considerations):
> 
> s/cache logotype data is cached/cache logotype data/
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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