Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

Ah, got it. Thanks.
Alissa

> On Jan 22, 2020, at 5:07 PM, Tommy Pauly <tpauly@apple.com> 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 <alissa@cooperw.in <mailto:alissa@cooperw.in>> 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 <tpauly@apple.com <mailto:tpauly@apple.com>> 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 <noreply@ietf.org <mailto:noreply@ietf.org>> 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
>>>> Int-area@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/int-area
>>> 
> 