Ah, got it. Thanks. Alissa > On Jan 22, 2020, at 5:07 PM, Tommy Pauly <[email protected]> wrote: > > 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] >> <mailto:[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] >>> <mailto:[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] <mailto:[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 >>>> <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/ >>>> <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
