Hi Alissa, I think the more likely example is 3GPP, using a sub-dictionary for 3GPP-specific extensions to how to manage and identify properties of given prefixes handed out to cellular network clients. Such sets could contain details for 5G network slicing, etc.
Thanks, Tommy > On Jan 22, 2020, at 1:57 PM, Alissa Cooper <[email protected]> wrote: > > Thanks Tommy. So why would, e.g., BBF or OASIS be using PvDs? Sorry if this > is obvious. > > Alissa > >> On Jan 22, 2020, at 12:02 PM, Tommy Pauly <[email protected]> wrote: >> >> Hi Alissa, >> >> Thanks very much for the review! I'm keeping pending changes available here, >> to be published after the telechat: >> https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25 >> <https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25> >> >> I've updated the URN reference to specify the correct URL; that was due to >> my errors in filling out the RFC markdown correctly! I've also updated the >> text that makes the reference to be clearer in intent: >> >> If a set of PvD Additional Information keys >> are defined by an organization that has a Formal URN Namespace {{URN}}, >> the URN namespace SHOULD be used rather than the "vendor-*" format. >> >> The unnecessary MAY has been removed, and the sentence now reads: >> >> If the HTTP status of >> the answer is between 200 and 299, inclusive, the response is expected to >> be a single JSON object. >> >> I've also changed "privacy address" to "temporary address" as suggested. >> >> Thanks, >> Tommy >> >>> On Jan 21, 2020, at 8:22 AM, Alissa Cooper via Datatracker >>> <[email protected]> wrote: >>> >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-intarea-provisioning-domains-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is a nit that should be easy to resolve but I'm confused by it, so I'm >>> flagging it here. The reference for [URN] in Section 10.2 says '[URN] "URN >>> Namespaces", n.d..,' which seems like an error. Given the way [URN] is used >>> in >>> 4.3, I'm not sure I understand why organizations with formal URN namespaces >>> <https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml#urn-namespaces-1> >>> would be expected to be using PvDs, if that is what the document intends to >>> convey. In any event, at a minimum the reference needs to be fixed. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> = Section 4.1 = >>> >>> "If the HTTP >>> status of the answer is between 200 and 299, inclusive, the host MAY >>> get a file containing a single JSON object." >>> >>> This seems like a misuse of normative MAY, as the behavior is determined by >>> the >>> sending server, not the host. >>> >>> = Section 7 = >>> >>> s/IPv6 Privacy Address/IPv6 temporary address/ >>> (to align with RFC 7721 terminology) >>> >>> >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/int-area >>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
