Subject: [alto] Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 22 Nov 2021 02:00:53 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-unified-props-new-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Vijay Gurbani for the shepherd's extended write-up about the
WG consensus (even if not using the usual template).

While the document supports clearly the two address families (IPv4 and IPv6), I
can only regret that the vast majority of examples are for IPv4.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

While the documents is very detailed, I would have preferred to have a generic
introduction of the concepts at the beginning. It also seems to me that part of
the text is repetitive.

-- Section 3.1 --
I am a little puzzled by the use of "TCP/IP network flow" as it mixes up
layers. Also, the "associated 5-tuple" is redundant because TCP has always 6 as
protocol so it is not really a 5-tuple as one is constant.

-- Section 4.6.1 --
The use of "ane" is done before its explanation later in section 4.6.2.

-- Section 5.1.3 --
"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a /128
address.

-- Section 10.4 (and possibly others) --
Please use RFC 5398 when using ASN in examples.

-- Section 10.9 --
Is the JSON reply valid ?

-- Section 13 --
No hard feeling but I find it strange that the acknowledgements section also
includes some affiliations.

== NITS ==

-- Section 10.1 --
RFC 5792 prefers ipv6:::/0 to ipv6:::0/0

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 25 Nov 2021 13:28:42 +0000

Hello Éric,

Thanks a lot for your review and comments. 
Please find our answers inline.
A version 21 is under edition and will integrate the changes upon your feedback.

Best regards, 
Sabine and co-authors

>-----Original Message-----
>From: Éric Vyncke via Datatracker <[email-masked]>
>Sent: Monday, November 22, 2021 11:01 AM
>To: The IESG <[email-masked]>
>Cc: [email-masked]; [email-masked];
>[email-masked]; Vijay Gurbani <[email-masked]>;
>[email-masked]
>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20:
>(with COMMENT)
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>Special thanks to Vijay Gurbani for the shepherd's extended write-up about
>the WG consensus (even if not using the usual template).
>
>While the document supports clearly the two address families (IPv4 and IPv6),
>I can only regret that the vast majority of examples are for IPv4.
>
>While the documents is very detailed, I would have preferred to have a
>generic introduction of the concepts at the beginning. It also seems to me that
>part of the text is repetitive.

[ [SR] ] The Introduction indeed, lists features such as entity, entity domain and its type, resource specific entity domain, Filtered/Property map, that are introduced at high level w.r.t. how they address the limitations of the current protocol. 

The generic  introduction of the concepts is provided right after the Introduction, in the 4 pages Section 3. "Basic Features of the Entity Property Map Extension". Section 3, in its introduction, also references a table that summarizes all the features introduced by this extension, in the paragraph below:
"The Entity Property Maps extension described in this document
introduces a number of features that are summarized in Appendix A,
where Table 4 lists the features and references the sections in this
document that give a high-level and normative description thereof." 

Do you think it would be helpful to move this paragraph to Section 1.Introduction, just before its last paragraph?
>
>-- Section 3.1 --
>I am a little puzzled by the use of "TCP/IP network flow" as it mixes up layers.
>Also, the "associated 5-tuple" is redundant because TCP has always 6 as
[ [SR] ] We propose to update item 5 as follows:
OLD
a TCP network flow, that is identified by a TCP 5-Tuple
specifying its source and destination addresses and port numbers
and the utilized protocol,
NEW
a TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple 
specifying its source and destination addresses and port numbers and the IP protocol

>The use of "ane" is done before its explanation later in section 4.6.2.
[ [SR] ] As citing "ane" does not add anything to understand the point, we propose to remove it. 
We propose to update sentence in parag 2 as follows:
OLD
...
This is useful for entity domain types that are by essence domain-specific, such as "pid" and "ane" domain types.
...
NEW
...
This is useful for entity domain types that are by essence domain-specific, such as the "pid" domain type.
...

>"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a /128
[ [SR] ] Thanks for catching this typo. We propose to replace "net1.ipv6:2001:db8::1/48" with "net1.ipv6:2001:db8::/48".
>
>-- Section 10.4 (and possibly others) -- Please use RFC 5398 when using ASN in
>examples.
>
[ [SR] ] following section  "4. IANA Considerations" of https://www.rfc-editor.org/rfc/pdfrfc/rfc5398.txt.pdf,
we will use either of the 64496 - 64511 and 65536 - 65551 blocks reserved by IANA for documentation purposes. 

Example ASN numbers 12345 and 12346 will be replaced with 65543, 65544

>Is the JSON reply valid ?
[ [SR] ] Indeed, the property values are not to be exposed with their units, thanks a lot for this catch. 
The units will be removed and the reply will look like:
OLD
.....
{"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores},
.....
NEW
.....
{"storage-capacity" : 40000, "cpu" : 500},

>includes some affiliations.
[ [SR] ] we will remove the affiliations

>RFC 5792 prefers ipv6:::/0 to ipv6:::0/0
[ [SR] ] Thanks a lot for catching this typo
We will replace " ipv6:::0/0" with " ipv6:::/0" in the examples

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 26 Nov 2021 13:57:26 +0000

Hello Éric,

A new version has been posted to address your comments. 
We hope the updates meet your expectation and will like to have your feedback.
Best regards,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-21

>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[email-masked]>
>Sent: Thursday, November 25, 2021 2:29 PM
>To: Éric Vyncke <[email-masked]>; The IESG <[email-masked]>
>[email-masked]; Vijay Gurbani <[email-masked]>
>Subject: RE: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-
>20: (with COMMENT)
>
>Hello Éric,
>
>>Please refer to
>>https://www.ietf.org/blog/handling-iesg-ballot-positions/
>>Please find below some non-blocking COMMENT points (but replies would
>>be appreciated even if only for my own education), and some nits.
>>
>>Special thanks to Vijay Gurbani for the shepherd's extended write-up
>>about the WG consensus (even if not using the usual template).
>>
>>While the document supports clearly the two address families (IPv4 and
>>IPv6), I can only regret that the vast majority of examples are for IPv4.
>>
>>generic introduction of the concepts at the beginning. It also seems to
>>me that part of the text is repetitive.
>
>[ [SR] ] The Introduction indeed, lists features such as entity, entity domain
>and its type, resource specific entity domain, Filtered/Property map, that are
>introduced at high level w.r.t. how they address the limitations of the current
>protocol.
>
>The generic  introduction of the concepts is provided right after the
>Introduction, in the 4 pages Section 3. "Basic Features of the Entity Property
>Map Extension". Section 3, in its introduction, also references a table that
>summarizes all the features introduced by this extension, in the paragraph
>below:
>"The Entity Property Maps extension described in this document introduces a
>number of features that are summarized in Appendix A, where Table 4 lists
>the features and references the sections in this document that give a high-
>level and normative description thereof."
>
>Do you think it would be helpful to move this paragraph to Section
>1.Introduction, just before its last paragraph?
>>
>>-- Section 3.1 --
>a TCP network flow, that is identified by a TCP 5-Tuple specifying its source
>and destination addresses and port numbers and the utilized protocol, NEW a
>TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple specifying its
>source and destination addresses and port numbers and the IP protocol
>
>>-- Section 4.6.1 --
>>"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a
>>/128 address.
>[ [SR] ] Thanks for catching this typo. We propose to replace
>"net1.ipv6:2001:db8::1/48" with "net1.ipv6:2001:db8::/48".
>>
>>-- Section 10.4 (and possibly others) -- Please use RFC 5398 when using
>>ASN in examples.
>>
>{"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores}, .....
>NEW
>.....
>>No hard feeling but I find it strange that the acknowledgements section
>>also includes some affiliations.
>>
>[ [SR] ] Thanks a lot for catching this typo We will replace " ipv6:::0/0" with "
>ipv6:::/0" in the examples
>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 26 Nov 2021 14:11:00 +0000

Bonjour Sabine,

Thank you for revision -21, it addresses all my previous non-blocking comments.

Have a nice WE!

Regards

-éric

On 26/11/2021, 14:57, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]> wrote:

    Hello Éric,

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 26 Nov 2021 14:43:57 +0000

Bonjour Éric,
Thanks a lot for your feedback,
Best regards,
Sabine

>From: Eric Vyncke (evyncke) <[email-masked]>
>Sent: Friday, November 26, 2021 3:11 PM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[email-masked]>; The IESG <[email-masked]>
>Subject: Re: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-
>20: (with COMMENT)
>
>Bonjour Sabine,
>
>On 26/11/2021, 14:57, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)"
><[email-masked]> wrote:
>
>    Hello Éric,
>
>introduces a
>layers.
>    >we will use either of the 64496 - 64511 and 65536 - 65551 blocks reserved
>by
>    >IANA for documentation purposes.
>    >