An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps
draft-ietf-alto-unified-props-new-24
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-07-01
|
24 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-05-09
|
24 | (System) | RFC Editor state changed to AUTH48 |
2022-04-14
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-03-03
|
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-03-02
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-03-02
|
24 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-02-28
|
24 | (System) | RFC Editor state changed to EDIT |
2022-02-28
|
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-02-28
|
24 | (System) | Announcement was received by RFC Editor |
2022-02-28
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-02-28
|
24 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-24.txt |
2022-02-28
|
24 | (System) | New version approved |
2022-02-28
|
24 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2022-02-28
|
24 | Sabine Randriamasy | Uploaded new revision |
2022-02-28
|
23 | (System) | IANA Action state changed to In Progress |
2022-02-28
|
23 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-02-28
|
23 | Cindy Morgan | IESG has approved the document |
2022-02-28
|
23 | Cindy Morgan | Closed "Approve" ballot |
2022-02-28
|
23 | Cindy Morgan | Ballot approval text was generated |
2022-02-26
|
23 | Martin Duke | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2022-02-25
|
23 | (System) | Removed all action holders (IESG state changed) |
2022-02-25
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-02-25
|
23 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-23.txt |
2022-02-25
|
23 | (System) | New version approved |
2022-02-25
|
23 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2022-02-25
|
23 | Sabine Randriamasy | Uploaded new revision |
2022-01-27
|
22 | (System) | Changed action holders to Y. Richard Yang, Sabine Randriamasy, Wendy Roome, Kai Gao, Jingxuan Zhang (IESG state changed) |
2022-01-27
|
22 | Martin Duke | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::AD Followup |
2022-01-27
|
22 | Benjamin Kaduk | [Ballot comment] Thanks for the updates in the -22 to resolve my previous Discuss! I have a couple new comments on the -22, and I … [Ballot comment] Thanks for the updates in the -22 to resolve my previous Discuss! I have a couple new comments on the -22, and I will include below that my ballot comments from the -21 (unchanged, so some of them, most notably for section 10.x, will no longer apply). === new comments on the -22 === Section 4.6.1 A defining information resource for an entity domain D is the information resource where entities of D are defined. That is, all [...] allocated by the IANA. This is useful for entity domain types that are by essence domain-specific, such as the "pid" domain type. It is Thanks for adding all the examples and clarification here (most of which I elided)! With all that new text, I'd suggest adding a couple words around "This is useful" to bring us back to the core concept of defining information resource, perhaps as "The defining information resource is useful". Section 8.6 The filtered property map response MUST include all the inherited property values for the requested entities and all the entities which are able to inherit property values from the requested entities. To achieve this goal, the ALTO server MAY follow two rules: In light of the other edits and discussion, I think this "MAY" might be fine in lowercase. === old comments on the -21, unchanged === I suggest noting somewhere early-ish that the (semi-)formal notation defined in Section 8.2 of RFC 7285 will be used. Section 1 properties. Furthermore, recent ALTO use cases show that properties of entities such as network flows [RFC7011] and routing elements [RFC7921] are also useful. Such cases are documented in [I-D.gao-alto-fcs]. The current EPS however is restricted to This is probably more relevant as a comment on draft-gao-alto-fcs than this document, but putting the ALTO server in a position to know about individual flows seems like a big privacy risk, especially in the face of pervasive monitoring (per RFC 7258). It's not really clear that this is actually a good idea to do, and thus whether we want to mention it here. Section 3.2.2 There seems to be an unfortunate risk of conflation of parsing as ((entity domain) name) vs (entity (domain name)), with domain name being the widely-used term (see, e.g., RFC 8499). Could we find some alternate terminology that doesn't suffer from this potential confusion? Section 4.4 For some domain types, entities can be grouped in a set and be defined by the identifier of this set. This is the case for domain From a mathematical/set-theoretic perspective, this statement is trivially true for all domain types; that's just how sets work. I think what we want to say here is that they can be efficiently grouped by utilizing an underlying structure for the entities in the given domain type. That might become, for example, "For some domain types, there is an underlying structure that allows entities to efficiently be grouped into a set and be defined by the identifier of this set". Section 4.6 Besides, it is also necessary to inform a Client about which associations of specific resources and entity domain types are allowed, because it is not possible to prevent a Server from exposing inappropriate associations. [...] This reasoning is a bit hard for me to follow. It's not possible to prevent a server from exposing nonsensical things, sure. But often we would just define the correct operation of the protocol to be only exposing things that make sense, and if the server is noncompliant to the spec, things break accordingly. Section 4.6.1 The defining information resource of a resource-specific entity domain D is unique and has the following specificities: [...] * its media type is unique and equal to the one that is specified for the defining information resource of an entity domain type. I find this definition worrisom, as it seems to imply that the given resource only has one media type, implicily precluding the server from ever exposing the representation of that resource via a different media type. This does not mesh well with my understanding of the HTTP ecosystem and the guidelines for using HTTP as a substrate for building other protocols. For example, in draft-ietf-httpbis-semantics, we see that the notion of an HTTP resource is in some sense an abstract resource, and HTTP only conveys representations of that resource. There can inherently be multiple representations of a given resource, and there is a media-type negotiation to determine what representation is returned. Likewise, in https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis#section-4.16 we see that it is an expected part of protocol evolution to define new media types that enable new functionality by virtue of the new format, even if the abstract resource being provided remains the same. A fundamental attribute of a defining information resource is its media type. There is a unique association between an entity domain Similarly here -- the media type is not a property of the resource, but rather of a representation that is conveyed over HTTP. [For brevity, I will try to not make further comments on this topic, though I think that the theme continues in other locations in the document.] I think that what ALTO wants is a new conceptual "ALTO resource type" that is distinct from an (HTTP) media type. Unfortunately, I see that RFC 7285 has already placed a strong emphasis on media types specifically, so addressing this topic might best be done as a separate work item. Section 5.1.1 [RFC8126] without a need to register with IANA. All other entity domain types appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered with the IANA, That's a rather unusually specific requirement to have it conditioned solely on the application/alto-* media type. Often when we have such a requirement we would consider adding a note to the registry to help remind reviewers that the requirement exists, but I would rather advocate for removing the media-type specificity of the requirement, here. (Also in §5.2.1.) A Private Use entity domain type identifier and its associated internal specification MUST apply to all the property maps of an IRD. I don't think I understand what this requirement is trying to say. The best reading I can come up with so far is that it says "if there is a private use type identifier presented in an IRD, that entity domain type must be present in all of the property maps in the IRD. On the face of it, that seems like an absurd requirement to meet, though, since even the primary types we're defining in this document are not going to all apply to all property maps. (Also in §5.2.1.) identifier) to reduce potential collisions. The format of the entity identifiers (see Section 5.1.3) in that type of entity domain, as well as any hierarchical or inheritance rules (see Section 5.1.4) for those entities, MUST be specified at the same time. What does "specified at the same time" mean? In the same document? Section 5.1.2.1 A resource-specific entity domain is identified by an entity domain name constructed as follows. It MUST start with a resource ID using the ResourceID type defined in Section 10.2 of [RFC7285], followed by the '.' separator (U+002E), followed by a string of the type EntityDomainType specified in Section 5.1.1. This seems to disallow using the "priv:" form for (the "type" part of) resource-specific entity domain names. Is that really intended? Section 5.1.2.3 A self-defined entity domain can be viewed as a particular case of resource-specific entity domain, where the specific resource is the current resource that uses this entity domain. In that case, for the sake of simplification, the component "ResourceID" SHOULD be omitted in its entity domain name. Why do we need the flexibility of allowing both X.X and .X to represent the same information? Wouldn't it be simpler to only allow one form? Having a single well-specified procedure tends to result in more secure implementations. Section 5.2.1 However, when applied to an entity in a "pid" domain type, the property would indicate the location of the center of all hosts in this "pid" entity. I'd consider saying something less specific, like "would indicate a location representative of all hosts in this "pid" entry", avoiding the term "center" that invites questions of how it is computed. (Similarly, §9.3 mentions the "barycenter" of a set of addresses.) Section 5.2.2 EntityPropertyName ::= [ResourceID]'.'[priv:]EntityPropertyType Should the "priv:" component be quoted here as a literal? Section 6.1.1.2 Individual addresses are strings as specified by the IPv4Addresses rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are prefix-match strings as specified in Section 3.1 of [RFC4632]. To The referenced section of RFC 4632 does not refer to "prefix-match strings" at all (and only once to "match" at all, not directly related to prefixes). Please use the terminology of the referenced document to indicate the functionality that is being integrated. Section 6.1.2.2 Individual addresses are strings as specified by Section 4 of [RFC5952]; Hierarchical addresses are prefix-match strings as specified in Section 7 of [RFC5952]. To define properties, an Is this the right reference for prefix-matching IPv6 addresses? Section 7 of RFC 5952 is quite short... Section 6.1.3 Both Internet address domains allow property values to be inherited. Specifically, if a property P is not defined for a specific Internet address I, but P is defined for a hierarchical Internet address C which prefix-matches I, then the address I inherits the value of P defined for the hierarchical address C. If more than one such I think there's some room for tightening up the terminology around "hierarchical" addresses. While we do use the term in some earlier parts of the document, it's not specifically defined anywhere that I found. The usage in this section, on the other hand, seems like it would be easy to replace with discussion of "prefix"es and avoid the need for a new term. If we do want to keep the "hierarchical" concept, I strongly suggest adding some terminology section that specifically defines what we use it to mean. Section 7.5 The "uses" field of a property map resource in an IRD entry specifies dependent resources of this property map. It is an array of the resource ID(s) of the resource(s). This doesn't seem to add anything above the definition of the "uses" field from RFC 7285; shouldn't we be saying something about the defining information resource for resource-specific domains/properties (in addition to any other dependent resources)? Section 8.3 If it is absent, the Server returns an empty property value '{}' for all the entity IDs of the "entities" field on which at least one property is defined. Is that the literal string "{}" or an empty JSON object? Given the SHOULD-level guidance we give elsewhere to assume that the response is a string (or JSON null value, which both {} and "{}" are not), it seems important to provide clarity on this matter. Section 8.6 Given that there are identifiers that can be interpreted as both an entity name and a property name, and we have the same error code for invalid entity identifier and invalid property name (with guidance to return the invalid identifier in the error message), are we setting up for a situation where the error message is ambiguous about which interpretation of the string was invalid? * The response only includes the entities and properties requested by the client. If an entity in the request is identified by a hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the response MUST cover properties for all identifiers in this hierarchical identifier. Just to check: the intent here is that we return all properties that are present on any address covered by the prefix, even though some of those properties may not be present on all addresses covered by the prefix? Section 10.x I am not really an HTTP expert, but the content-lengths in these examples seem to be based on byte counts with Unix-style line separators, whereas (per draft-ietf-httpbis-messaging) my understanding is that the values should be computed with CRLF as the line separator. Section 10.2 Beyond "pid", the examples in this section use four additional properties for Internet address domains, "ISP", "ASN", "country" and "state", with the following values: Are these property names, types, or both? Should we use "countrycode" that is defined by draft-ietf-alto-cdni-request-routing-alto, rather than the very similar sounding "country"? Section 10.3 The following IRD defines ALTO Server information resources that are relevant to the Entity Property Service. It provides two property maps: one for the "ISP" and "ASN" properties, and another one for the "country" and "state" properties. [...] I may be misreading things, but I could only find the former of these two. I should be looking for resources that have the "application/alto-propmap+json" media-type and do not accept parameters, right? The server provides several filtered property maps. The first returns all four properties, and the second returns only the "pid" property for the default network map. Does it also return the "pid" property for the alt-network-map? The filtered property maps for the "ISP", "ASN", "country" and "state" properties do not depend on the default network map (it does not have a "uses" capability), because the definitions of those I only see "ISP" showing up in the ia-property-map and the iacs-property-map, both of which list "uses" for the default-network-map. Note that for legacy clients, the ALTO server provides an Endpoint Property Service for the "pid" property defined on the endpoints of the default network map. Also the alt-network-map? I think there are a couple other property maps in the returned IRD that are not mentioned in the prose at all (not sure if they need to be). Section 10.4 Note that, to be compact, the response does not include the entity "ipv4:192.0.2.0", because values of all those properties for this entity are inherited from other entities. Is this really the single IP address, equivalent to 192.0.2.0/32? I don't see why it's special enough to get called out, as opposed to the other addresses in 192.0.2.0/27. The same rule applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". Should one of these be 192.0.3.16/28? Section 10.5 Note that the value of "state" for "ipv4:192.0.2.0" is the only explicitly defined property; the other values are all derived by the inheritance rules for Internet address entities. I think the .2.1 is explicitly defined and .2.0 is inherited... "property-map": { "ipv4:192.0.2.0": {".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"}, "ipv4:192.0.2.1": {".ISP": "BitsRus", ".ASN": "65543", ".state": "NJ"}, "ipv4:192.0.2.17": {".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"} ...and my reading of the table in §10.2 would have .2.0 as NJ and .2.1 as PA. Section 10.6 "ipv4:192.0.2.0": {".state": "PA"}, As above, I think this has to be .2.1. "ipv4:192.0.3.0/28": {".ASN": "65543", ".state": "TX"}, "ipv4:192.0.3.16/28": {".ASN": "65543", ".state": "MN"} These ASNs should be 65544. Section 11 endpoint properties conveyed by using [RFC7285]. Client requests may reveal details on their activity or plans thereof, that a malicious user may monetize or use for attacks or undesired surveillance. This would be a malicious Server that's in a position to do so, right (vs. "user")? Section 12.1 Security considerations: Security considerations related to the generation and consumption of ALTO Protocol messages are discussed in Section 15 of [RFC7285]. I think we should also reference Section 11 of this document as having relevant considerations. Section 12.2, 12.3 Should we write "priv:*" or some other wildcard to indicate that this entry is for the class of identifiers beginning with that prefix, and not the literal identifier "priv:"? Section 14.1 The RFC 5246 is unused (in favor of RFC 8446, thanks!). Section 14.2 If it's RECOMMENDED to use the RFC 8895 mechanisms, that seems to promote 8895 to be a normative reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ NITS Section 1 and IPv6 addresses. It is reasonable to think that collections of endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have We haven't defined PIDs yet. At first, a map of endpoint properties might seem impractical, because it could require enumerating the property value for every possible endpoint. However, in practice, the number of endpoint addresses involved by an ALTO server can be quite large. To avoid This doesn't seem like a "however" that contrasts the previous point; rather, it seems like an "in particular" that expounds on the scale of impracticality. and Filtered Property Map, detailed in Section 8. The former is a GET-mode resource that returns the property values for all entities in one or more entity domains, and is analogous to a network map or a cost map in [RFC7285]. The latter is a POST-mode The terms "GET-mode" and "POST-mode" don't seem to be defined or used in RFC 7285, so we probably need to introduce them here if we're going to use them. Section 4.4 grouped in blocks. When a same property value applies to a whole set, a Server can define a property for the identifier of this set instead of enumerating all the entities and their properties. This s/a same/the same/ Section 4.4.1 An entity domain may allow using a single identifier to identify a set of individual entities. For example, a CIDR block can be used to I suggest "set of related individual entities". Section 5.2.2 The specific information resource of an entity property may be the current information resource itself, that is, the property map defining the property. In that case, the ResourceID in the property name SHOULD be ignored. For example, the property name ".asn" I think s/ignored/omitted/. Section 6.1.3 Hierarchical addresses can also inherit properties: if a property P is not defined for the hierarchical address C, but is defined for a set of hierarchical addresses, where each address C' in the set covers all IP addresses in C, and C' has a shorter prefix length than I think the usage of "set" and "covers" is unclear here. (Also, pedantically, the empty set is a set, and any statement of the form " holds for each element of the set" is true for the empty set, but there is no C' in the empty set to have a shorter prefix length than C.) * If that entity would inherit a value for that property, then the ALTO server MUST return a "null" value for that property. In this This is the JSON "null" value, at least for the currently defined media types, right? That might be worth clarifying (while retaining the generic nature not tied to a JSON representation). * If the entity would not inherit a value, then the ALTO server MAY return "null" or just omit the property. In this case, the ALTO client cannot infer the value for this property of this entity from the Inheritance rules. So the client MUST interpret that this property has no value. This probably doesn't need to be a BCP 14 keyword, as the behavior follows from the other required parts of the spec. Section 7.6 entity does. The ALTO client MUST ignore any resource-specific property for this entity if its mapping is not indicated, in the IRD, in the "mappings" capability of the property map resource. The pronoun "its" might be anti-helpful here, as (if I understand correctly) we mean to say that the the entity domain that's the defining information resource for this resource-specific property is what's listed in the capabilities map, but "its" leaves the exact relation a bit under-specified. Section 8 query. To support such a case, the filtered property map provides a light weight response, with empty property values. This might be (mis?)read as saying that the filtered property map *always* provides a response with empty property values. So I'd suggest adding a qualifier, like "provides a facility for" or "supports a lightweight response". Section 8.1 The media type of a property map resource is "application/alto- propmap+json". Do we want "filtered" here? Section 8.3 ReqFilteredPropertyMap. The design of object ReqFilteredPropertyMap supports the following cases of client requests: The grammar seems off, here -- maybe "the object" or just "ReqFilteredPropertyMap is designed to support"? Section 8.6 * When the input member "properties" is absent from the client request, the Server returns a property map containaing all the s/containaing/containing/ |
2022-01-27
|
22 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2022-01-25
|
22 | Francesca Palombini | [Ballot comment] Thank you for the work on this document, and thanks to the authors for addressing my previous DISCUSS and COMMENTs. Many thanks to … [Ballot comment] Thank you for the work on this document, and thanks to the authors for addressing my previous DISCUSS and COMMENTs. Many thanks to Spencer Dawkins for his thoughtful review: https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ , and to Alexey Melnikov for his media-types review. I keep the only COMMENT left in v-22. Francesca 1. ----- 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. |
2022-01-25
|
22 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to No Objection from Discuss |
2022-01-25
|
22 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-01-25
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-01-25
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-01-25
|
22 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-22.txt |
2022-01-25
|
22 | (System) | New version approved |
2022-01-25
|
22 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2022-01-25
|
22 | Sabine Randriamasy | Uploaded new revision |
2021-12-14
|
21 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-12-06
|
21 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-12-04
|
21 | Murray Kucherawy | [Ballot comment] I support Francesca's DISCUSS. The shepherd writeup says: The chair has received IPR declarations from Richard Yang, Sabine Randriamasy, Jensen Zhang, … [Ballot comment] I support Francesca's DISCUSS. The shepherd writeup says: The chair has received IPR declarations from Richard Yang, Sabine Randriamasy, Jensen Zhang, Wendy Roome, and Kai Gao. During the discussion of this I-D in the working group, no IPR issues has been raised to the best of my knowledge. Just to be clear, I presume what the chair actually received was affirmations of compliance with BCP 78 and 79 from those people, and not declarations of the existence of IPR. The "Interoperability considerations" part of Section 12.1 doesn't seem to be a complete answer to the corresponding guidance in Section 6.2 of RFC 6838. I'm bothered by the dangling SHOULD in Section 12.2.2. If you're going to include that, I suggest including some guidance about when it would be legitimate to omit that information from a registration and still expect it to go through. The second-last paragraph in Section 12.3 appears to be broken. For Sections 12.2 and 12.3, I suggest not including a registry entry for "priv:" because that's not an identifier, but everything else is. It's fine to leave in prose saying nothing can be registered using "priv:" as a prefix, as those are meant to indicate private use. [I-D.gao-alto-fcs] has expired. What's the plan here? It's an informative reference. I had the same thought as Ben did about the use of "GET-mode" and "POST-mode". It's a pity that the referenced documents didn't use ABNF, because it seems like Sections 5.1.1 and 5.1.2 would benefit from it. But ultimately, I agree with the decision to be consistent. Also in 5.1.1, it seems strange to issue constraints for how private use entity domain types are to be specified. If they're private use, interoperability is the concern of those participants only. Sections 6.1.1.1 and 6.1.2.1 (and later, 6.2.1) should include more than a single word. I suggest something like: The identifier for this Entity Domain Type is "ipv4". In Section 6.2.3, "is" should be "are". Do we need Section 7.3? If we do, please turn it into at least a single sentence, like: A Property Map has no Accept Input parameters. |
2021-12-04
|
21 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-12-02
|
21 | (System) | Changed action holders to Martin Duke, Y. Richard Yang, Sabine Randriamasy, Wendy Roome, Kai Gao, Jingxuan Zhang (IESG state changed) |
2021-12-02
|
21 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-12-02
|
21 | Zaheduzzaman Sarker | [Ballot comment] I think this document has already got comments and nits that showed up in my review. So, no objection and hopping those comments … [Ballot comment] I think this document has already got comments and nits that showed up in my review. So, no objection and hopping those comments will be addressed. I am supporting Francesca's DISCUSS on media type registration though. |
2021-12-02
|
21 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-12-01
|
21 | Benjamin Kaduk | [Ballot discuss] (1) Section 8.6 seems to have some conflicting requirements. The filtered property map response "MUST include all the inherited property values for the … [Ballot discuss] (1) Section 8.6 seems to have some conflicting requirements. The filtered property map response "MUST include all the inherited property values for the requested entities and all the entities which are able to inherit property values from the requested entities." We then go on to say that to do this, the server MAY follow three rules, that themselves include SHOULD-level guidance, but don't say how the MUST is achieved if the SHOULDs or MAY are ignored. I was expecting to see a construction of the form "SHOULD do X, but if not, MUST do Y". (2) Many of the examples in Sections 10.X do not seem to match up with the prose that describes them and the previous data tables that they are intended to illustrate (see COMMENT). We should make sure that the examples are internally consistent. (3) Section 4.6.2 says: * Last, the entity domain types "asn" and "countrycode" defined in [I-D.ietf-alto-cdni-request-routing-alto] do not have a defining information resource. Indeed, the entity identifiers in these two entity domain types are already standardized in documents that the Client can use. But earlier we said that "the defining information resource of a resource-specific entity domain D is unique", but this seems to be saying that the defining information resource of domains of the "asn" and "contrycode" type are *not* unique, by virtue of not existing at all. How can we rectify these two statements? |
2021-12-01
|
21 | Benjamin Kaduk | [Ballot comment] I suggest noting somewhere early-ish that the (semi-)formal notation defined in Section 8.2 of RFC 7285 will be used. Section 1 properties. … [Ballot comment] I suggest noting somewhere early-ish that the (semi-)formal notation defined in Section 8.2 of RFC 7285 will be used. Section 1 properties. Furthermore, recent ALTO use cases show that properties of entities such as network flows [RFC7011] and routing elements [RFC7921] are also useful. Such cases are documented in [I-D.gao-alto-fcs]. The current EPS however is restricted to This is probably more relevant as a comment on draft-gao-alto-fcs than this document, but putting the ALTO server in a position to know about individual flows seems like a big privacy risk, especially in the face of pervasive monitoring (per RFC 7258). It's not really clear that this is actually a good idea to do, and thus whether we want to mention it here. Section 3.2.2 There seems to be an unfortunate risk of conflation of parsing as ((entity domain) name) vs (entity (domain name)), with domain name being the widely-used term (see, e.g., RFC 8499). Could we find some alternate terminology that doesn't suffer from this potential confusion? Section 4.4 For some domain types, entities can be grouped in a set and be defined by the identifier of this set. This is the case for domain From a mathematical/set-theoretic perspective, this statement is trivially true for all domain types; that's just how sets work. I think what we want to say here is that they can be efficiently grouped by utilizing an underlying structure for the entities in the given domain type. That might become, for example, "For some domain types, there is an underlying structure that allows entities to efficiently be grouped into a set and be defined by the identifier of this set". Section 4.6 Besides, it is also necessary to inform a Client about which associations of specific resources and entity domain types are allowed, because it is not possible to prevent a Server from exposing inappropriate associations. [...] This reasoning is a bit hard for me to follow. It's not possible to prevent a server from exposing nonsensical things, sure. But often we would just define the correct operation of the protocol to be only exposing things that make sense, and if the server is noncompliant to the spec, things break accordingly. Section 4.6.1 The defining information resource of a resource-specific entity domain D is unique and has the following specificities: [...] * its media type is unique and equal to the one that is specified for the defining information resource of an entity domain type. I find this definition worrisom, as it seems to imply that the given resource only has one media type, implicily precluding the server from ever exposing the representation of that resource via a different media type. This does not mesh well with my understanding of the HTTP ecosystem and the guidelines for using HTTP as a substrate for building other protocols. For example, in draft-ietf-httpbis-semantics, we see that the notion of an HTTP resource is in some sense an abstract resource, and HTTP only conveys representations of that resource. There can inherently be multiple representations of a given resource, and there is a media-type negotiation to determine what representation is returned. Likewise, in https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-bcp56bis#section-4.16 we see that it is an expected part of protocol evolution to define new media types that enable new functionality by virtue of the new format, even if the abstract resource being provided remains the same. A fundamental attribute of a defining information resource is its media type. There is a unique association between an entity domain Similarly here -- the media type is not a property of the resource, but rather of a representation that is conveyed over HTTP. [For brevity, I will try to not make further comments on this topic, though I think that the theme continues in other locations in the document.] I think that what ALTO wants is a new conceptual "ALTO resource type" that is distinct from an (HTTP) media type. Unfortunately, I see that RFC 7285 has already placed a strong emphasis on media types specifically, so addressing this topic might best be done as a separate work item. Section 5.1.1 [RFC8126] without a need to register with IANA. All other entity domain types appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered with the IANA, That's a rather unusually specific requirement to have it conditioned solely on the application/alto-* media type. Often when we have such a requirement we would consider adding a note to the registry to help remind reviewers that the requirement exists, but I would rather advocate for removing the media-type specificity of the requirement, here. (Also in §5.2.1.) A Private Use entity domain type identifier and its associated internal specification MUST apply to all the property maps of an IRD. I don't think I understand what this requirement is trying to say. The best reading I can come up with so far is that it says "if there is a private use type identifier presented in an IRD, that entity domain type must be present in all of the property maps in the IRD. On the face of it, that seems like an absurd requirement to meet, though, since even the primary types we're defining in this document are not going to all apply to all property maps. (Also in §5.2.1.) identifier) to reduce potential collisions. The format of the entity identifiers (see Section 5.1.3) in that type of entity domain, as well as any hierarchical or inheritance rules (see Section 5.1.4) for those entities, MUST be specified at the same time. What does "specified at the same time" mean? In the same document? Section 5.1.2.1 A resource-specific entity domain is identified by an entity domain name constructed as follows. It MUST start with a resource ID using the ResourceID type defined in Section 10.2 of [RFC7285], followed by the '.' separator (U+002E), followed by a string of the type EntityDomainType specified in Section 5.1.1. This seems to disallow using the "priv:" form for (the "type" part of) resource-specific entity domain names. Is that really intended? Section 5.1.2.3 A self-defined entity domain can be viewed as a particular case of resource-specific entity domain, where the specific resource is the current resource that uses this entity domain. In that case, for the sake of simplification, the component "ResourceID" SHOULD be omitted in its entity domain name. Why do we need the flexibility of allowing both X.X and .X to represent the same information? Wouldn't it be simpler to only allow one form? Having a single well-specified procedure tends to result in more secure implementations. Section 5.2.1 However, when applied to an entity in a "pid" domain type, the property would indicate the location of the center of all hosts in this "pid" entity. I'd consider saying something less specific, like "would indicate a location representative of all hosts in this "pid" entry", avoiding the term "center" that invites questions of how it is computed. (Similarly, §9.3 mentions the "barycenter" of a set of addresses.) Section 5.2.2 EntityPropertyName ::= [ResourceID]'.'[priv:]EntityPropertyType Should the "priv:" component be quoted here as a literal? Section 6.1.1.2 Individual addresses are strings as specified by the IPv4Addresses rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are prefix-match strings as specified in Section 3.1 of [RFC4632]. To The referenced section of RFC 4632 does not refer to "prefix-match strings" at all (and only once to "match" at all, not directly related to prefixes). Please use the terminology of the referenced document to indicate the functionality that is being integrated. Section 6.1.2.2 Individual addresses are strings as specified by Section 4 of [RFC5952]; Hierarchical addresses are prefix-match strings as specified in Section 7 of [RFC5952]. To define properties, an Is this the right reference for prefix-matching IPv6 addresses? Section 7 of RFC 5952 is quite short... Section 6.1.3 Both Internet address domains allow property values to be inherited. Specifically, if a property P is not defined for a specific Internet address I, but P is defined for a hierarchical Internet address C which prefix-matches I, then the address I inherits the value of P defined for the hierarchical address C. If more than one such I think there's some room for tightening up the terminology around "hierarchical" addresses. While we do use the term in some earlier parts of the document, it's not specifically defined anywhere that I found. The usage in this section, on the other hand, seems like it would be easy to replace with discussion of "prefix"es and avoid the need for a new term. If we do want to keep the "hierarchical" concept, I strongly suggest adding some terminology section that specifically defines what we use it to mean. Section 7.5 The "uses" field of a property map resource in an IRD entry specifies dependent resources of this property map. It is an array of the resource ID(s) of the resource(s). This doesn't seem to add anything above the definition of the "uses" field from RFC 7285; shouldn't we be saying something about the defining information resource for resource-specific domains/properties (in addition to any other dependent resources)? Section 8.3 If it is absent, the Server returns an empty property value '{}' for all the entity IDs of the "entities" field on which at least one property is defined. Is that the literal string "{}" or an empty JSON object? Given the SHOULD-level guidance we give elsewhere to assume that the response is a string (or JSON null value, which both {} and "{}" are not), it seems important to provide clarity on this matter. Section 8.6 Given that there are identifiers that can be interpreted as both an entity name and a property name, and we have the same error code for invalid entity identifier and invalid property name (with guidance to return the invalid identifier in the error message), are we setting up for a situation where the error message is ambiguous about which interpretation of the string was invalid? * The response only includes the entities and properties requested by the client. If an entity in the request is identified by a hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the response MUST cover properties for all identifiers in this hierarchical identifier. Just to check: the intent here is that we return all properties that are present on any address covered by the prefix, even though some of those properties may not be present on all addresses covered by the prefix? Section 10.x I am not really an HTTP expert, but the content-lengths in these examples seem to be based on byte counts with Unix-style line separators, whereas (per draft-ietf-httpbis-messaging) my understanding is that the values should be computed with CRLF as the line separator. Section 10.2 Beyond "pid", the examples in this section use four additional properties for Internet address domains, "ISP", "ASN", "country" and "state", with the following values: Are these property names, types, or both? Should we use "countrycode" that is defined by draft-ietf-alto-cdni-request-routing-alto, rather than the very similar sounding "country"? Section 10.3 The following IRD defines ALTO Server information resources that are relevant to the Entity Property Service. It provides two property maps: one for the "ISP" and "ASN" properties, and another one for the "country" and "state" properties. [...] I may be misreading things, but I could only find the former of these two. I should be looking for resources that have the "application/alto-propmap+json" media-type and do not accept parameters, right? The server provides several filtered property maps. The first returns all four properties, and the second returns only the "pid" property for the default network map. Does it also return the "pid" property for the alt-network-map? The filtered property maps for the "ISP", "ASN", "country" and "state" properties do not depend on the default network map (it does not have a "uses" capability), because the definitions of those I only see "ISP" showing up in the ia-property-map and the iacs-property-map, both of which list "uses" for the default-network-map. Note that for legacy clients, the ALTO server provides an Endpoint Property Service for the "pid" property defined on the endpoints of the default network map. Also the alt-network-map? I think there are a couple other property maps in the returned IRD that are not mentioned in the prose at all (not sure if they need to be). Section 10.4 Note that, to be compact, the response does not include the entity "ipv4:192.0.2.0", because values of all those properties for this entity are inherited from other entities. Is this really the single IP address, equivalent to 192.0.2.0/32? I don't see why it's special enough to get called out, as opposed to the other addresses in 192.0.2.0/27. The same rule applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". Should one of these be 192.0.3.16/28? Section 10.5 Note that the value of "state" for "ipv4:192.0.2.0" is the only explicitly defined property; the other values are all derived by the inheritance rules for Internet address entities. I think the .2.1 is explicitly defined and .2.0 is inherited... "property-map": { "ipv4:192.0.2.0": {".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"}, "ipv4:192.0.2.1": {".ISP": "BitsRus", ".ASN": "65543", ".state": "NJ"}, "ipv4:192.0.2.17": {".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"} ...and my reading of the table in §10.2 would have .2.0 as NJ and .2.1 as PA. Section 10.6 "ipv4:192.0.2.0": {".state": "PA"}, As above, I think this has to be .2.1. "ipv4:192.0.3.0/28": {".ASN": "65543", ".state": "TX"}, "ipv4:192.0.3.16/28": {".ASN": "65543", ".state": "MN"} These ASNs should be 65544. Section 11 endpoint properties conveyed by using [RFC7285]. Client requests may reveal details on their activity or plans thereof, that a malicious user may monetize or use for attacks or undesired surveillance. This would be a malicious Server that's in a position to do so, right (vs. "user")? Section 12.1 Security considerations: Security considerations related to the generation and consumption of ALTO Protocol messages are discussed in Section 15 of [RFC7285]. I think we should also reference Section 11 of this document as having relevant considerations. Section 12.2, 12.3 Should we write "priv:*" or some other wildcard to indicate that this entry is for the class of identifiers beginning with that prefix, and not the literal identifier "priv:"? Section 14.1 The RFC 5246 is unused (in favor of RFC 8446, thanks!). Section 14.2 If it's RECOMMENDED to use the RFC 8895 mechanisms, that seems to promote 8895 to be a normative reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ NITS Section 1 and IPv6 addresses. It is reasonable to think that collections of endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have We haven't defined PIDs yet. At first, a map of endpoint properties might seem impractical, because it could require enumerating the property value for every possible endpoint. However, in practice, the number of endpoint addresses involved by an ALTO server can be quite large. To avoid This doesn't seem like a "however" that contrasts the previous point; rather, it seems like an "in particular" that expounds on the scale of impracticality. and Filtered Property Map, detailed in Section 8. The former is a GET-mode resource that returns the property values for all entities in one or more entity domains, and is analogous to a network map or a cost map in [RFC7285]. The latter is a POST-mode The terms "GET-mode" and "POST-mode" don't seem to be defined or used in RFC 7285, so we probably need to introduce them here if we're going to use them. Section 4.4 grouped in blocks. When a same property value applies to a whole set, a Server can define a property for the identifier of this set instead of enumerating all the entities and their properties. This s/a same/the same/ Section 4.4.1 An entity domain may allow using a single identifier to identify a set of individual entities. For example, a CIDR block can be used to I suggest "set of related individual entities". Section 5.2.2 The specific information resource of an entity property may be the current information resource itself, that is, the property map defining the property. In that case, the ResourceID in the property name SHOULD be ignored. For example, the property name ".asn" I think s/ignored/omitted/. Section 6.1.3 Hierarchical addresses can also inherit properties: if a property P is not defined for the hierarchical address C, but is defined for a set of hierarchical addresses, where each address C' in the set covers all IP addresses in C, and C' has a shorter prefix length than I think the usage of "set" and "covers" is unclear here. (Also, pedantically, the empty set is a set, and any statement of the form " holds for each element of the set" is true for the empty set, but there is no C' in the empty set to have a shorter prefix length than C.) * If that entity would inherit a value for that property, then the ALTO server MUST return a "null" value for that property. In this This is the JSON "null" value, at least for the currently defined media types, right? That might be worth clarifying (while retaining the generic nature not tied to a JSON representation). * If the entity would not inherit a value, then the ALTO server MAY return "null" or just omit the property. In this case, the ALTO client cannot infer the value for this property of this entity from the Inheritance rules. So the client MUST interpret that this property has no value. This probably doesn't need to be a BCP 14 keyword, as the behavior follows from the other required parts of the spec. Section 7.6 entity does. The ALTO client MUST ignore any resource-specific property for this entity if its mapping is not indicated, in the IRD, in the "mappings" capability of the property map resource. The pronoun "its" might be anti-helpful here, as (if I understand correctly) we mean to say that the the entity domain that's the defining information resource for this resource-specific property is what's listed in the capabilities map, but "its" leaves the exact relation a bit under-specified. Section 8 query. To support such a case, the filtered property map provides a light weight response, with empty property values. This might be (mis?)read as saying that the filtered property map *always* provides a response with empty property values. So I'd suggest adding a qualifier, like "provides a facility for" or "supports a lightweight response". Section 8.1 The media type of a property map resource is "application/alto- propmap+json". Do we want "filtered" here? Section 8.3 ReqFilteredPropertyMap. The design of object ReqFilteredPropertyMap supports the following cases of client requests: The grammar seems off, here -- maybe "the object" or just "ReqFilteredPropertyMap is designed to support"? Section 8.6 * When the input member "properties" is absent from the client request, the Server returns a property map containaing all the s/containaing/containing/ |
2021-12-01
|
21 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-12-01
|
21 | Francesca Palombini | [Ballot 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 … [Ballot 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. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. 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. 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). |
2021-12-01
|
21 | Francesca Palombini | Ballot discuss text updated for Francesca Palombini |
2021-12-01
|
21 | Francesca Palombini | [Ballot 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 … [Ballot 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. 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). |
2021-12-01
|
21 | Francesca Palombini | [Ballot comment] 3. ----- identifier. In this case, inheritance rules must specify how entities in "subsets" inherit property values from their "superset". … [Ballot 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") 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. 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). 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" 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. |
2021-12-01
|
21 | Francesca Palombini | [Ballot Position Update] New position, Discuss, has been recorded for Francesca Palombini |
2021-11-30
|
21 | Roman Danyliw | [Ballot comment] Thank you to Paul Wouters for the SECDIR review. ** Section 3.1. This section provides a list of examples of entities, but doesn’t … [Ballot comment] Thank you to Paul Wouters for the SECDIR review. ** Section 3.1. This section provides a list of examples of entities, but doesn’t cite a few of them. For example: -- as = should be [I-D.ietf-alto-cdni-request-routing-alto] -- country = should be [I-D.ietf-alto-cdni-request-routing-alto] -- network flow = ? -- routing element = ? ** Section 3.2.1 An entity domain type MUST be registered at the IANA, as specified in section Section 12.2.2 and similarly to an ALTO address type. Per the text in Section 12.2.2, it doesn’t appear that a binding to an ALTO address type is required. For example neither pid or priv have an “ALTO address type”. ** Section 4.6 Besides, it is also necessary to inform a Client about which associations of specific resources and entity domain types are allowed, because it is not possible to prevent a Server from exposing inappropriate associations. An informed Client will just ignore inappropriate associations exposed by a Server and avoid error-prone transactions with the Server. -- Editorial, s/Besides, it is also/It is also/ -- What does it mean that it’s “necessary to inform a Client about which associations”? I was under the impression that this section was documenting the IRD capability behavior which is triggered by the client. If so, the client “is asking” in this interaction model rather than being “informed”. -- What is meant by “it is not possible to prevent a Server from exposing inappropriate associations”? Is it envisioned that the Server might respond with an associations which isn’t self-consistent with another part of the property map? ** Section 4.6 For example, the association "costmap3.pid" is not allowed for the following reason: although a cost map exposes PID identifiers, it does not define the set of addresses included in this PID. I don’t follow what this example is trying to demonstrate – in that, how is it related to the what’s supported in the IRD capability. From the explanation, it appears that a costmap and a pid can never be mixed. No query to an IRD would be needed to know that. ** Section 5.1.1. Would “_”, “-“, “__--" be considered valid EntityDomainTypes? If so, is that desirable? (it's perfectly reasonable to say "absolutely") ** Section 5.1.1 For an endpoint domain type identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid entity domain type identifier) to reduce potential collisions. I found this language confusing. “priv:” is not a domain type identifier. It’s only a prefix to the domain type identifier. It couldn’t be a domain type identifier because the colon is not permitted in things of type EntityDomainType. Is this text effectively saying that EntityDomainType has to be a non-zero length string, which should be true whether “priv:” is used or not. If so, I’d recommend being clearer. ** Section 5.2.1. -- What’s the thinking on EntityPropertyType having a colon, but EntityDomainType (Section 5.1.1) cannot? -- Could “:” or “_::-“ be a valid EntityPropertyType? If so, is that desirable? (it's perfectly reasonable to say "absolutely") ===[ Nits ** Section 1. Editorial At first, a map of endpoint properties might seem impractical, because it could require enumerating the property value for every possible endpoint. However, in practice, the number of endpoint addresses involved by an ALTO server can be quite large. The “However, in practice ” part doesn’t follow from the previous sentence. s/However, in practice, the number/The number/ ** Section 3.3. Editorial. s/Likewise, a same/Likewise, the same/ ** Section 5.1.3. Editorial. OLD The format of the second part of an entity identifier depends on the entity domain type, and MUST be specified when defining a new entity domain type and registering it with the IANA. NEW The format of the second part of an entity identifier, DomainTypeSpecificEntityID, depends on the entity domain type, and MUST be specified when defining a new entity domain type and registering it with the IANA. ** Section 8.6. Typo. s/contanaing/containing/ ** Section 9.3. Typo. s/is is/is/ ** Section 9.3. Typo. s/hierachical/hierarchical/ |
2021-11-30
|
21 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-11-30
|
21 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-11-29
|
21 | Erik Kline | [Ballot comment] [S4.2, nit] * s/relatively to/relative to/, I think [S4.3, nit] * s/be be/be/ [S4.4.2, comment] * I think the last sentence of the … [Ballot comment] [S4.2, nit] * s/relatively to/relative to/, I think [S4.3, nit] * s/be be/be/ [S4.4.2, comment] * I think the last sentence of the paragraph might be trying to say "may or may not inherit the property P...", because the inheritance rules for the property lowercase-must be defined? Also: lowercase must? [S6.1.2.2, comment] * I gather there is no value to allowing link-local scope identifiers to appear here. The current text does not support such a thing, but perhaps consider whether or not to explicitly note that "%25", "%eth0" are invalid. Maybe it doesn't need an explicit mention, though. [S6.1.3, question] * Can this "undef" behavior be used to explicitly undefine an inherited property? For example, can "v4" be replaced with some "null" indicator in Figure 1 such that "ipv4:192.0.2.0/32" in Figure 2 becomes "(not defined)"? If there is no such mechanism, should there be? |
2021-11-29
|
21 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-11-26
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-11-26
|
21 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-21.txt |
2021-11-26
|
21 | (System) | New version accepted (logged-in submitter: Sabine Randriamasy) |
2021-11-26
|
21 | Sabine Randriamasy | Uploaded new revision |
2021-11-22
|
20 | Éric Vyncke | [Ballot 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 … [Ballot 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 |
2021-11-22
|
20 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-10-26
|
20 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-10-26
|
20 | Cindy Morgan | Placed on agenda for telechat - 2021-12-02 |
2021-10-25
|
20 | Martin Duke | Ballot has been issued |
2021-10-25
|
20 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
2021-10-25
|
20 | Martin Duke | Created "Approve" ballot |
2021-10-25
|
20 | Martin Duke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-10-25
|
20 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-20.txt |
2021-10-25
|
20 | (System) | New version approved |
2021-10-25
|
20 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2021-10-25
|
20 | Sabine Randriamasy | Uploaded new revision |
2021-10-25
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-10-25
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2021-10-25
|
19 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-19.txt |
2021-10-25
|
19 | (System) | New version approved |
2021-10-25
|
19 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2021-10-25
|
19 | Sabine Randriamasy | Uploaded new revision |
2021-09-15
|
18 | Paul Wouters | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Paul Wouters. Sent review to list. |
2021-09-09
|
18 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Team Will not Review Version' |
2021-09-09
|
18 | Jean Mahoney | Assignment of request for Last Call review by GENART to Suhas Nandakumar was marked no-response |
2021-09-07
|
18 | Spencer Dawkins | Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Spencer Dawkins. Sent review to list. |
2021-08-27
|
18 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-08-27
|
18 | Martin Duke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup::Revised I-D Needed |
2021-08-27
|
18 | Martin Duke | Ballot writeup was changed |
2021-08-27
|
18 | Martin Duke | - Please respond to the OPSDIR review - Please respond to the IANA concerns |
2021-08-27
|
18 | (System) | Changed action holders to Martin Duke, Y. Richard Yang, Sabine Randriamasy, Wendy Roome, Kai Gao, Jingxuan Zhang (IESG state changed) |
2021-08-27
|
18 | Martin Duke | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2021-08-27
|
18 | Martin Duke | Ballot writeup was changed |
2021-08-26
|
18 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-08-25
|
18 | Scott Bradner | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Scott Bradner. Sent review to list. |
2021-08-24
|
18 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-08-24
|
18 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-alto-unified-props-new-18. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-alto-unified-props-new-18. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. We understand that, upon approval of this document, there are three actions which we must complete. First, in the application registry on the Media Types registry page located at: https://www.iana.org/assignments/media-types/ two new registrations are to be made as follows: Name: alto-propmap+json Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Name: alto-propmapparams+json Template: [ TBD-at-Registration ] Reference: [ RFC-to-be ] Second, a new registry is to be created called the ALTO Entity Domain Type Registry. IANA Question --> Where should this new registry be located? Should it be on the Application-Layer Traffic Optimization (ALTO) Protocol registry page located at: https://www.iana.org/assignments/alto-protocol/? Should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? New registrations for the ALTO Entity Domain Type Registry are managed via IETF Review as defined in RFC8126. There are three initial registrations in the new registry as follows: Identifier: ipv4 Entity Identifier Encoding: [ RFC-to-be; Section 6.1.1 ] Hierarchy and Inheritance: [ RFC-to-be; Section 6.1.3 ] Media Type of Defining Resource: application/alto-networkmap+json Mapping to ALTO Address Type: true Reference: [ RFC-to-be ] Identifier: ipv6 Entity Identifier Encoding: [ RFC-to-be; Section 6.1.2 ] Hierarchy and Inheritance: [ RFC-to-be; Section 6.1.3 ] Media Type of Defining Resource: application/alto-networkmap+json Mapping to ALTO Address Type: true Reference: [ RFC-to-be ] Identifier: pid Entity Identifier Encoding: [ RFC-to-be; Section 6.2 ] Hierarchy and Inheritance: None Media Type of Defining Resource: application/alto-networkmap+json Mapping to ALTO Address Type: false Reference: [ RFC-to-be ] Third, a new registry is to be created called the ALTO Entity Property Type Registry. IANA Question --> Where should this new registry be located? Should it be on the Application-Layer Traffic Optimization (ALTO) Protocol registry page located at: https://www.iana.org/assignments/alto-protocol/? Should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? IANA Question --> is this document closing the existing ALTO Endpoint Property Type registry [RFC7285] to new registrations? New registrations for the ALTO Entity Property Type Registry are managed via IETF Review as defined in RFC8126. There is a single initial registration in the new registry as follows: Identifier: pic Intended Semantics: [ RFC7285; Section 7.1.1 ] Media Type of Defining Resource: application/alto-networkmap+json Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2021-08-19
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2021-08-19
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2021-08-19
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suhas Nandakumar |
2021-08-19
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suhas Nandakumar |
2021-08-16
|
18 | Barry Leiba | Request for Last Call review by ARTART is assigned to Spencer Dawkins |
2021-08-16
|
18 | Barry Leiba | Request for Last Call review by ARTART is assigned to Spencer Dawkins |
2021-08-13
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2021-08-13
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2021-08-12
|
18 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-08-12
|
18 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-08-26): From: The IESG To: IETF-Announce CC: Vijay Gurbani , alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-unified-props-new@ietf.org, … The following Last Call announcement was sent out (ends 2021-08-26): From: The IESG To: IETF-Announce CC: Vijay Gurbani , alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-unified-props-new@ietf.org, martin.h.duke@gmail.com, vijay.gurbani@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (ALTO Extension: Entity Property Maps) to Proposed Standard The IESG has received a request from the Application-Layer Traffic Optimization WG (alto) to consider the following document: - 'ALTO Extension: Entity Property Maps' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends the base Application-Layer Traffic Optimization (ALTO) Protocol by generalizing the concept of "endpoint properties" to entities defined by a wide set of objects, instead of only IP addresses. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. The protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ No IPR declarations have been submitted directly on this I-D. |
2021-08-12
|
18 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-08-12
|
18 | Martin Duke | Last call was requested |
2021-08-12
|
18 | Martin Duke | Last call announcement was generated |
2021-08-12
|
18 | Martin Duke | Ballot approval text was generated |
2021-08-12
|
18 | Martin Duke | Ballot writeup was generated |
2021-08-12
|
18 | Martin Duke | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-08-12
|
18 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-08-12
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-08-12
|
18 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-18.txt |
2021-08-12
|
18 | (System) | New version approved |
2021-08-12
|
18 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2021-08-12
|
18 | Sabine Randriamasy | Uploaded new revision |
2021-07-02
|
17 | (System) | Changed action holders to Martin Duke, Y. Yang, Sabine Randriamasy, Wendy Roome, Kai Gao, Jingxuan Zhang (IESG state changed) |
2021-07-02
|
17 | Martin Duke | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-06-15
|
17 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2021-06-15
|
17 | Martin Duke | IESG state changed to AD Evaluation from Publication Requested |
2021-06-15
|
17 | Vijay Gurbani | Shepherd writeup for draft-ietf-alto-unified-props-new-17 1. Summary. The document shepherd is Vijay K. Gurbani, and the responsible area director is Martin Duke. The document is a … Shepherd writeup for draft-ietf-alto-unified-props-new-17 1. Summary. The document shepherd is Vijay K. Gurbani, and the responsible area director is Martin Duke. The document is a Standards Track document, targeted as a Proposed Standard. The WG has chosen the requested publication type since this draft extends the base ALTO protocol in a normative manner. Specifically, the document seeks to extend the base ALTO protocol (RFC 7285) by generalizing certain properties attached to ALTO endpoints. 2. Review and consensus. The document has a long history in the ALTO WG, having first made its appearance as an individual draft in March 2017, and was formally adopted as a WG item in April 2017 [1]. It is an important draft as two other WG drafts depend on the extensions defined in it. A WGLC was issued for the draft on July 2020 [2]. Two reviewers were identified that provided a detailed WGLC review [3,4]. The draft has broad consensus across the WG, no specific shortcomings have been identified with the current version of the draft. Over the years that the draft has been active in the WG, it has been subject to revisions based on the WG expectations. At least three implementations of unified-props are known. The first implementation was by one of the authors (Wendy Roome), corresponding to an older version of the draft. A WG member (not a co-author) has implemented unified-props as well (details on the exact version implemented are not known). And finally, a small group of WG members (including one co-author) are planning to implement the latest version of the draft as part of an open GitHub community [5]. 3. Intellectual property The chair has received IPR declarations from Richard Yang, Sabine Randriamasy, Jensen Zhang, Wendy Roome, and Kai Gao. During the discussion of this I-D in the working group, no IPR issues has been raised to the best of my knowledge. 4. Other points The document shepherd conducted a formal review of version 15 [6,7]; the comments raised by the shepherd have been addressed in versions 16 and 17. IDNits on version 17 reports: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Please fix these during AUTH48. [1] https://mailarchive.ietf.org/arch/msg/alto/iz8dIQtwkjZHZYrI8q4JDOyZPPI/ [2] https://mailarchive.ietf.org/arch/msg/alto/jhPmZR4UKpiIwA_tC2s9b9YZ8Mk/ [3] https://mailarchive.ietf.org/arch/msg/alto/YVaCXE7IgXOqWpq-17GV-gbiYwo/ [4] https://mailarchive.ietf.org/arch/msg/alto/EnKuKcnxfeAsg5eBtEbmuFf1cCw/ [5] https://github.com/openalto/sextant [6] https://mailarchive.ietf.org/arch/msg/alto/7ZCGFIoT9OnZBNYOzUONbI53IxM/ [7] https://mailarchive.ietf.org/arch/msg/alto/9_YFODK1EnXz0YNW-RT7hbAzTiU/ |
2021-06-15
|
17 | Vijay Gurbani | Responsible AD changed to Martin Duke |
2021-06-15
|
17 | Vijay Gurbani | IETF WG state changed to Submitted to IESG for Publication from Held by WG |
2021-06-15
|
17 | Vijay Gurbani | IESG state changed to Publication Requested from I-D Exists |
2021-06-15
|
17 | Vijay Gurbani | IESG process started in state Publication Requested |
2021-06-15
|
17 | Vijay Gurbani | Changed consensus to Yes from Unknown |
2021-06-15
|
17 | Vijay Gurbani | Intended Status changed to Proposed Standard from None |
2021-06-15
|
17 | Vijay Gurbani | Clearing tags and moving to IESG. |
2021-06-15
|
17 | Vijay Gurbani | Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WGLC, Other - see Comment Log cleared. |
2021-06-15
|
17 | Vijay Gurbani | Shepherd writeup for draft-ietf-alto-unified-props-new-17 1. Summary. The document shepherd is Vijay K. Gurbani, and the responsible area director is Martin Duke. The document is a … Shepherd writeup for draft-ietf-alto-unified-props-new-17 1. Summary. The document shepherd is Vijay K. Gurbani, and the responsible area director is Martin Duke. The document is a Standards Track document, targeted as a Proposed Standard. The WG has chosen the requested publication type since this draft extends the base ALTO protocol in a normative manner. Specifically, the document seeks to extend the base ALTO protocol (RFC 7285) by generalizing certain properties attached to ALTO endpoints. 2. Review and consensus. The document has a long history in the ALTO WG, having first made its appearance as an individual draft in March 2017, and was formally adopted as a WG item in April 2017 [1]. It is an important draft as two other WG drafts depend on the extensions defined in it. A WGLC was issued for the draft on July 2020 [2]. Two reviewers were identified that provided a detailed WGLC review [3,4]. The draft has broad consensus across the WG, no specific shortcomings have been identified with the current version of the draft. Over the years that the draft has been active in the WG, it has been subject to revisions based on the WG expectations. At least three implementations of unified-props are known. The first implementation was by one of the authors (Wendy Roome), corresponding to an older version of the draft. A WG member (not a co-author) has implemented unified-props as well (details on the exact version implemented are not known). And finally, a small group of WG members (including one co-author) are planning to implement the latest version of the draft as part of an open GitHub community [5]. 3. Intellectual property The chair has received IPR declarations from Richard Yang, Sabine Randriamasy, Jensen Zhang, Wendy Roome, and Kai Gao. During the discussion of this I-D in the working group, no IPR issues has been raised to the best of my knowledge. 4. Other points The document shepherd conducted a formal review of version 15 [6,7]; the comments raised by the shepherd have been addressed in versions 16 and 17. IDNits on version 17 reports: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Please fix these during AUTH48. [1] https://mailarchive.ietf.org/arch/msg/alto/iz8dIQtwkjZHZYrI8q4JDOyZPPI/ [2] https://mailarchive.ietf.org/arch/msg/alto/jhPmZR4UKpiIwA_tC2s9b9YZ8Mk/ [3] https://mailarchive.ietf.org/arch/msg/alto/YVaCXE7IgXOqWpq-17GV-gbiYwo/ [4] https://mailarchive.ietf.org/arch/msg/alto/EnKuKcnxfeAsg5eBtEbmuFf1cCw/ [5] https://github.com/openalto/sextant [6] https://mailarchive.ietf.org/arch/msg/alto/7ZCGFIoT9OnZBNYOzUONbI53IxM/ [7] https://mailarchive.ietf.org/arch/msg/alto/9_YFODK1EnXz0YNW-RT7hbAzTiU/ |
2021-06-15
|
17 | Vijay Gurbani | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2021-04-22
|
17 | Martin Duke | None |
2021-04-16
|
17 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-17.txt |
2021-04-16
|
17 | (System) | New version approved |
2021-04-16
|
17 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Kai Gao , Sabine Randriamasy , Wendy Roome |
2021-04-16
|
17 | Sabine Randriamasy | Uploaded new revision |
2021-02-22
|
16 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-16.txt |
2021-02-22
|
16 | (System) | New version approved |
2021-02-22
|
16 | (System) | Request for posting confirmation emailed to previous authors: "J. Zhang" , "Y. Yang" , Kai Gao , Sabine Randriamasy , Wendy Roome |
2021-02-22
|
16 | Sabine Randriamasy | Uploaded new revision |
2021-02-08
|
15 | Vijay Gurbani | Shepherd review of I-D done. Waiting for I-D to be revised. |
2021-02-08
|
15 | Vijay Gurbani | Tags Doc Shepherd Follow-up Underway, Other - see Comment Log set. |
2020-11-26
|
15 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-15.txt |
2020-11-26
|
15 | (System) | New version approved |
2020-11-26
|
15 | (System) | Request for posting confirmation emailed to previous authors: "J. Zhang" , "Y. Yang" , Wendy Roome , Kai Gao , Sabine Randriamasy |
2020-11-26
|
15 | Sabine Randriamasy | Uploaded new revision |
2020-11-19
|
14 | Jan Seedorf | Tag Revised I-D Needed - Issue raised by WGLC set. Tag Doc Shepherd Follow-up Underway cleared. |
2020-11-19
|
14 | Jan Seedorf | IETF WG state changed to Held by WG from In WG Last Call |
2020-11-18
|
14 | Martin Duke | Shepherding AD changed to Martin Duke |
2020-11-17
|
14 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-14.txt |
2020-11-17
|
14 | (System) | New version approved |
2020-11-17
|
14 | (System) | Request for posting confirmation emailed to previous authors: Sabine Randriamasy , "J. Zhang" , Kai Gao , Wendy Roome , "Y. Yang" |
2020-11-17
|
14 | Sabine Randriamasy | Uploaded new revision |
2020-11-05
|
13 | Vijay Gurbani | Tag Doc Shepherd Follow-up Underway set. |
2020-11-05
|
13 | Vijay Gurbani | IETF WG state changed to In WG Last Call from WG Document |
2020-11-02
|
13 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-13.txt |
2020-11-02
|
13 | (System) | New version approved |
2020-11-02
|
13 | (System) | Request for posting confirmation emailed to previous authors: "J. Zhang" , "Y. Yang" , Sabine Randriamasy , Kai Gao , Wendy Roome |
2020-11-02
|
13 | Sabine Randriamasy | Uploaded new revision |
2020-09-25
|
12 | Vijay Gurbani | Notification list changed to Vijay Gurbani <vijay.gurbani@gmail.com> |
2020-09-25
|
12 | Vijay Gurbani | Document shepherd changed to Vijay K. Gurbani |
2020-07-13
|
12 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-12.txt |
2020-07-13
|
12 | (System) | New version approved |
2020-07-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: Wendy Roome , Kai Gao , "J. Zhang" , "Y. Yang" , Sabine Randriamasy |
2020-07-13
|
12 | Sabine Randriamasy | Uploaded new revision |
2020-03-09
|
11 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-11.txt |
2020-03-09
|
11 | (System) | New version approved |
2020-03-09
|
11 | (System) | Request for posting confirmation emailed to previous authors: Sabine Randriamasy , alto-chairs@ietf.org, Kai Gao , "Y. Yang" , "J. Zhang" , Wendy Roome |
2020-03-09
|
11 | Jingxuan Zhang | Uploaded new revision |
2019-11-04
|
10 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-10.txt |
2019-11-04
|
10 | (System) | New version approved |
2019-11-04
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome , Sabine Randriamasy , Kai Gao , alto-chairs@ietf.org, "J. Zhang" |
2019-11-04
|
10 | Jingxuan Zhang | Uploaded new revision |
2019-09-04
|
09 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-09.txt |
2019-09-04
|
09 | (System) | New version approved |
2019-09-04
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Y. Yang" , alto-chairs@ietf.org, Sabine Randriamasy , "J. Zhang" , Wendy Roome |
2019-09-04
|
09 | Jingxuan Zhang | Uploaded new revision |
2019-07-08
|
08 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-08.txt |
2019-07-08
|
08 | (System) | New version approved |
2019-07-08
|
08 | (System) | Request for posting confirmation emailed to previous authors: Wendy Roome , Sabine Randriamasy , "J. Zhang" , Yang Yang |
2019-07-08
|
08 | Jingxuan Zhang | Uploaded new revision |
2019-03-11
|
07 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-07.txt |
2019-03-11
|
07 | (System) | New version approved |
2019-03-11
|
07 | (System) | Request for posting confirmation emailed to previous authors: Yang Yang , Wendy Roome , Sabine Randriamasy , Shiwei Chen , alto-chairs@ietf.org, "J. Zhang" |
2019-03-11
|
07 | Jingxuan Zhang | Uploaded new revision |
2019-01-02
|
06 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-06.txt |
2019-01-02
|
06 | (System) | New version approved |
2019-01-02
|
06 | (System) | Request for posting confirmation emailed to previous authors: Wendy Roome , Sabine Randriamasy , "J. Zhang" , Yang Yang , Shiwei Chen |
2019-01-02
|
06 | Jingxuan Zhang | Uploaded new revision |
2018-12-10
|
05 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-05.txt |
2018-12-10
|
05 | (System) | New version approved |
2018-12-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Wendy Roome , Sabine Randriamasy , "J. Zhang" , Yang Yang , Shiwei Chen |
2018-12-10
|
05 | Jingxuan Zhang | Uploaded new revision |
2018-06-29
|
04 | Sabine Randriamasy | New version available: draft-ietf-alto-unified-props-new-04.txt |
2018-06-29
|
04 | (System) | New version approved |
2018-06-29
|
04 | (System) | Request for posting confirmation emailed to previous authors: Wendy Roome , Sabine Randriamasy , "J. Zhang" , Yang Yang , Shiwei Chen |
2018-06-29
|
04 | Sabine Randriamasy | Uploaded new revision |
2018-03-05
|
03 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-03.txt |
2018-03-05
|
03 | (System) | New version approved |
2018-03-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: Sabine Randriamasy , Yang Yang , Wendy Roome , Shiwei Chen , alto-chairs@ietf.org, "J. Zhang" |
2018-03-05
|
03 | Jingxuan Zhang | Uploaded new revision |
2018-03-01
|
02 | Jingxuan Zhang | New version available: draft-ietf-alto-unified-props-new-02.txt |
2018-03-01
|
02 | (System) | New version approved |
2018-03-01
|
02 | (System) | Request for posting confirmation emailed to previous authors: Yang Yang , Wendy Roome , " xinwang2014@hotmail.com" , Shiwei Chen , alto-chairs@ietf.org, "J. Zhang" |
2018-03-01
|
02 | Jingxuan Zhang | Uploaded new revision |
2017-12-17
|
01 | Shiwei Chen | New version available: draft-ietf-alto-unified-props-new-01.txt |
2017-12-17
|
01 | (System) | New version approved |
2017-12-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: alto-chairs@ietf.org, Yang Yang , Wendy Roome |
2017-12-16
|
01 | Shiwei Chen | Uploaded new revision |
2017-07-20
|
00 | Jan Seedorf | This document now replaces draft-roome-alto-unified-props-new instead of None |
2017-07-20
|
00 | Y. Richard Yang | New version available: draft-ietf-alto-unified-props-new-00.txt |
2017-07-20
|
00 | (System) | WG -00 approved |
2017-07-20
|
00 | Y. Richard Yang | Set submitter to ""Y. Richard Yang" ", replaces to draft-roome-alto-unified-props-new and sent approval email to group chairs: alto-chairs@ietf.org |
2017-07-20
|
00 | Y. Richard Yang | Uploaded new revision |