Subject: [art] Art-Art Last Call review of draft-ietf-alto-path-vector-16

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Aug 2021 14:38:42 -0400

I am the assigned Art-Art reviewer for this draft. The Art Area
Review Team (Art-Art) reviews all Art Area IETF documents being 
processed by the IESG for the IETF Chair.  Please treat these comments 
just like any other last call comments.

Document: draft-ietf-alto-path-vector-16
Reviewer: Paul Kyzivat
Review Date: 2021-06-29
IETF LC End Date: ???
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

General:

This document is well written. The content was challenging for this 
reviewer who is not acquainted with the subject domain. Hence comments 
here are superficial.

Issues:

Major: 0
Minor: 1
Nits:  1

1) Minor: Use of Content-ID

This document makes use of Content-ID with constrained syntax and 
values. This usage *ought* to be consistent with http and mime 
definitions of Content-ID syntax.

I'm actually having some difficulty in identifying the most recent 
authoritative document for this syntax. The IANA registry of http header 
field names refers to RFC4229, and it refers to "The HTTP Distribution 
and Replication Protocol", W3C NOTE NOTE-drp-19970825, August 1997. That 
reference seems oddly specialized to be the authoritative definition. In 
any case it defines it as:

content-identifier = URI ( "," URI )*

A traditional one is <left@right> with some constraints on the content 
of left and right.

I'm not going to be the judge of what is authoritative here, but I 
suggest you find out and then conform to it.

2) NIT: Use of IPv6

As noted by IdNits, you should consider including some IPv6 addresses in 
examples.

---

From: [email-masked]
Date: Tue, 31 Aug 2021 10:10:27 +0800 (GMT+08:00)

Hi Paul,

Thanks for the comments. We will address them in the next revision (-18).

According to IANA [1], there are two entries for the "Content-ID" header field, one for HTTP and one for MIME. In our case, as the multipart message is involved, we should follow the format in RFC 2387 where "Content-ID" is specified to have the same format of "msg-id". The most recent specification for "msg-id" we find is RFC 5322 (2008) and it has the format of <left@right>. We will update the draft accordingly to conform to the format.

Thanks!

Best,
Kai

[1] https://www.iana.org/assignments/message-headers/message-headers.xhtml

"Paul Kyzivat" &lt;[email-masked]&gt;wrote:
&gt; I am the assigned Art-Art reviewer for this draft. The Art Area
&gt; Review Team (Art-Art) reviews all Art Area IETF documents being 
&gt; processed by the IESG for the IETF Chair.  Please treat these comments 
&gt; just like any other last call comments.
&gt; 
&gt; Document: draft-ietf-alto-path-vector-16
&gt; Reviewer: Paul Kyzivat
&gt; Review Date: 2021-06-29
&gt; IETF LC End Date: ???
&gt; IESG Telechat date: ?
&gt; 
&gt; Summary:
&gt; 
&gt; This draft is on the right track but has open issues, described in the 
&gt; review.
&gt; 
&gt; General:
&gt; 
&gt; This document is well written. The content was challenging for this 
&gt; reviewer who is not acquainted with the subject domain. Hence comments 
&gt; here are superficial.
&gt; 
&gt; Issues:
&gt; 
&gt; Major: 0
&gt; Minor: 1
&gt; Nits:  1
&gt; 
&gt; 1) Minor: Use of Content-ID
&gt; 
&gt; This document makes use of Content-ID with constrained syntax and 
&gt; values. This usage *ought* to be consistent with http and mime 
&gt; definitions of Content-ID syntax.
&gt; 
&gt; I'm actually having some difficulty in identifying the most recent 
&gt; authoritative document for this syntax. The IANA registry of http header 
&gt; field names refers to RFC4229, and it refers to "The HTTP Distribution 
&gt; and Replication Protocol", W3C NOTE NOTE-drp-19970825, August 1997. That 
&gt; reference seems oddly specialized to be the authoritative definition. In 
&gt; any case it defines it as:
&gt; 
&gt; content-identifier = URI ( "," URI )*
&gt; 
&gt; A traditional one is <left@right> with some constraints on the content 
&gt; of left and right.
&gt; 
&gt; I'm not going to be the judge of what is authoritative here, but I 
&gt; suggest you find out and then conform to it.
&gt; 
&gt; 2) NIT: Use of IPv6
&gt; 
&gt; As noted by IdNits, you should consider including some IPv6 addresses in 
&gt; examples.
</left@right></left@right>