Hello Francesca,
Thanks again for your review and feedback. As you know a new version V23 has
been posted.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23
It addresses one remaining comment of yours, regarding Sections 5.1.1, 5.2.1,
hopefully meeting your expectations. Please see our proposed updates below.
Thanks,
Sabine and co-authors
------------------------------------
Sections 5.1.1, 5.2.1
FP: As it is defined now, all Private Use type identifiers are not valid,
because they contain ":". I understand the intention, but it would be good to
clarify in the text.
===> (sabine & co-authors) We have updated Sections 5.1.1 and 5.2.1 so as to
address other review comments related to this issue.
- In 5.1.1 ":" is now allowed for entity domain type identifiers with
restricted use
- In 5.1.2. Entity Domain Name, the entity domain name format is updated
accordingly
- In 5.2.1, ":" is allowed with no restrictions, to allow using endpoint
properties defined in conformance with RFC7285, on entity domain types that
have a mapping with ALTO address types as per section 12.3 / Table 2. We added
a paragraph to explain this.
Please see the updates below. For brevity, when too long, only the NEW UPDATED
text is cited here.
----------
NEW - UPDATED
5.1.1. Entity Domain Type
An entity domain has a type, which is uniquely identified by a string
that MUST be no more than 64 characters, and MUST NOT contain
characters other than US-ASCII alphanumeric characters
(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
U+002D), the colon (':', U+003A), or the low line ('_', U+005F).
The usage of colon (':', U+003A) MUST obey the rules below:
* The colon (':', U+003A) character MUST NOT appear more than once,
* The colon character MUST NOT be used unless within the string
"priv:",
* The string "priv:" MUST NOT be used unless it starts the string
that identifies an entity domain type,
* For an entity domain type identifier with the "priv:" prefix , an
additional string (e.g., company identifier or random string) MUST
follow "priv:", to reduce potential collisions.
For example, the strings "ipv4", "ipv6", "pid" and "priv:example-
test-edt", are valid entity domain types. "ipv4.anycast", "pid.local"
and "priv:" are invalid.
Although "_", "-", "__--" are valid entity domain types, it is
desirable to add characters such as alphanumeric ones, for better
intelligibility.
The type EntityDomainType is used in this document to denote a JSON
string meeting the preceding requirements.
An entity domain type defines the semantics of a type of entity,
independently of any specifying resource. All entity domain types
that are not prefixed with "priv:" MUST be registered with the IANA,
in the "ALTO Entity Domain Type Registry", defined in Section 12.3,
following the procedure specified in Section 12.3.2 of this document.
The format of the entity identifiers (see Section 5.1.3) in that
entity domain type, as well as any hierarchical or inheritance rules
(see Section 5.1.4) for those entities, MUST be specified in the IANA
registration.
Entity domain type identifiers prefixed with "priv:" are reserved for
Private Use (see [RFC8126]) without a need to register with IANA.
The definition of a private use entity domain type MUST apply the
same way in all property maps of an IRD where it is present.
----------
5.1.2. Entity Domain Name
OLD
EntityDomainName ::= [[ResourceID] '.' ][priv:]EntityDomainType
The presence and construction of component
"[ [ ResourceID ] '.' ]"
depends on the category of entity domain.
The component
"[priv:]"
is present when the entity domain type is defined for Private Use.
NEW
EntityDomainName ::= [[ResourceID] '.' ]EntityDomainType
The presence and construction of the component
"[ [ ResourceID ] '.' ]"
depends on the category of entity domain.
----------
5.2.1. Entity Property Type
after parag. 1, we inserted a new one
NEW
While, in Section 5.1.1, character ":" is allowed with restrictions
on entity domain identifiers, it can be used without restrictions on
entity property type identifiers. This relates to [RFC7285], where a
Server can define properties on endpoints "ipv4" and "ipv6". In the
present extension, there is a mapping of ALTO entity domain types
"ipv4" and "ipv6", to ALTO address types "ipv4" and "ipv6".
Properties defined on "ipv4" and "ipv6" endpoints should be re-usable
on "ipv4" and "ipv6" entities. Forbidding the usage of ":" in a non-
private entity property type identifier would not allow to use
properties previously defined on "ipv4" and "ipv6" endpoints because
their identifiers would be invalid.
From: Francesca Palombini <[email protected]>
Sent: Tuesday, January 25, 2022 3:01 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; Vijay Gurbani <[email protected]>
Subject: Re: Francesca Palombini's Discuss on
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Hi Sabine,
Thanks for addressing my review. I have cleared my DISCUSS (and kept the one
COMMENT while waiting for the update), I believe the IANA section looks good
now, and thanks for the clarifications, they did help me.
Francesca
From: iesg <[email protected]<mailto:[email protected]>> on behalf of
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]<mailto:[email protected]>>
Date: Tuesday, 25 January 2022 at 14:50
To: Francesca Palombini
<[email protected]<mailto:[email protected]>>,
The IESG <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Vijay Gurbani <[email protected]<mailto:[email protected]>>
Subject: RE: Francesca Palombini's Discuss on
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Dear Francesca and Alexeï,
We have posted a revision that addresses the DISCUSS points raised in
Francesca's review. In particular, regarding the IANA registration, we would
like to have the feedback of Alexeï.
It is available here.
We also addressed the COMMENTS of Francesca's review, except the one on the
"priv:" prefix for entity domain types and property types. This COMMETN will be
addressed in the next revision, where we plan to add a seperate section for
private use entity domain types and property types.
Please see inline for our proposed updates.
We look forward to having your feedback,
best regards,
Sabine
>-----Original Message-----
>From: Francesca Palombini via Datatracker
><[email protected]<mailto:[email protected]>>
>Sent: Wednesday, December 1, 2021 7:36 PM
>To: The IESG <[email protected]<mailto:[email protected]>>
>Cc:
>[email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
>[email protected]<mailto:[email protected]>; Vijay Gurbani
><[email protected]<mailto:[email protected]>>;
>[email protected]<mailto:[email protected]>
>Subject: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-
>21: (with DISCUSS and COMMENT)
>
>Francesca Palombini has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>Thank you for the work on this document.
>
>Many thanks to Spencer Dawkins for his thoughtful review:
>https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ ,
>and thanks to the authors for addressing it.
>
>I have two blocking comments, and some non blocking comments (to which I
>would still appreciate answers) below.
>
>Francesca
>
>1. -----
>
>Media type registration
>
>FP: I haven't seen the media type being reviewed by the media-type mailing
>list, as requested by RFC 6838. Before progressing the document, I would
>really appreciate the authors to post the registrations to the media-type
>mailing list for review.
>
[ [SR] ] We have updated the IANA sections 12.1 and 12.2 accordingly, under
the guidance that Alexeï provided for CDNI and this draft.
>2. -----
>
>Sections 4.6.1, 12.2.2 and 12.3
>
>FP: The use of the term "unique" when referred to media types and entity
>domains (or properties) is confusing - it makes it sound as if the authors mean
>that each different entity domain (or property) is to be associated with a
>different unique media type, which doesn't seem to be the intent. As this is
>related to the media type registration, I believe this should be clarified and
>possibly checked with the media type experts (so it would be good to copy
>paste the relevant text in the email to the media-type mailing list).
>
[ [SR] ] the text has been hopefully clarified as follows:
--- section 4.6.1: parag 3, item 5.
OLD
its media type is unique and equal to the one that is specified
for the defining information resource of an entity domain type
NEW
its media type is equal to the one that is specified
for the defining information resource of the entity domain type of D
NEW
--- section 12.3 .2 (was 12.2.2 in version 21), parag 3, item 5
OLD
...
The authorized
media type of a defining information resources MUST be unique and
MUST be specified in the document defining the entity domain type.
When an entity domain type allows combinations with defining
resources, this MUST be indicated here, together with the
authorized media type for the defining resources
....
NEW
...
For each entity domain type, the potential defining information resources
have one common media type. This unique common media type is specific to
the entity domain type and MUST be specified.
...
--- Section 12.4, parag 6, item 3
OLD
...
The media type of the possibly used defining information resource MUST be
unique and MUST be specified here, as well as in the document that defines the
property type
...
NEW
...
For each property type, the potential defining information resources have one
common media type. This unique common media type is specific to the property
type and MUST be specified.
...
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>3. -----
>
> identifier. In this case, inheritance rules must specify how
> entities in "subsets" inherit property values from their "superset".
> For instance, if a property P is defined only for the entity set
> identified by address block "ipv4:192.0.1.0/24", the entity set
> identified by "ipv4:192.0.1.0/30" and thus included in the former
> set, may inherit the property P value from set "ipv4:192.0.1.0/24".
>
>FP: Are the sets inverted in the paragraph above? (should it be
>"ipv4:192.0.1.0/24" inherits from "ipv4:192.0.1.0/30")
>
[ [SR] ] They are not. Is the wording below clearer?
OLD
For instance, if a property P is defined only for the entity set
identified by address block "ipv4:192.0.1.0/24", the entity set
identified by "ipv4:192.0.1.0/30" and thus included in the former
set, may inherit the property P value from set "ipv4:192.0.1.0/24".
NEW
For instance, suppose a property P is defined only for the entity set defined
by address block "ipv4:192.0.1.0/24".
We know that entity set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24".
Therefore, the entities of "ipv4:192.0.1.0/30"may inherit the value of
property P from set "ipv4:192.0.1.0/24".
>4. -----
>
>Sections 5.1.1, 5.2.1
>
>FP: As it is defined now, all Private Use type identifiers are not valid,
>because
>they contain ":". I understand the intention, but it would be good to clarify
>in
>the text.
>
[ [SR] ] this will be addressed in the next revision, where we plan to add a
seperate section for private use entity domain types and property types.
>5. -----
>
>Section 5.1.2
>
>FP: Please add a note specifying the syntax used and a reference to it (it's
>enough to just mention it the first time it appears, so in this section).
>
[ [SR] ] we updated in parag 3 as follows and added a reference for RFC 5511:
OLD
Each entity domain is identified by a unique entity domain name which is a
string of the following format:
NEW
Each entity domain is identified by a unique entity domain name.
Borrowing the symbol "::=" from the Backus-Naur Form notation [RFC 5511], the
format of an entity domain name is defined as follows:
with RFC5511 added to section 4.2. Informative References
"Routing Backus-Naur Form (RBNF): A Syntax Used to Form
Encoding Rules in Various Routing Protocol Specifications",
Adrian Farrel, Old Dog Consulting, April 2009
>6. -----
>
> they have the same value of the "ASN" property. The same rule
> applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28".
>
>FP: I believe the second one should be "ipv4:192.0.3.16/28"
>
[ [SR] ] ===> Indeed, thanks, this has been corrected and the content-length
updated
>7. -----
>
> "properties" : [ "default-network-map.pid",
> "alt-network-map.pid ]
>
>FP: I validated the JSON examples (which I recommend to do) and this one is
>the only one that didn't validate as this is missing a closing " after "alt-
>network-map.pid.
>
[ [SR] ] Thanks, this has been corrected.
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
