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

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> 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> 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> 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
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>> 