Subject: [Int-area] Mirja Kühlewind's Yes on draft-ietf-intarea-provisioning-domains-10: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 20 Jan 2020 09:43:02 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-intarea-provisioning-domains-10: Yes

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written document (and thanks Martin for the TSV-ART
review)!

I have no real issues but two quick questions:

1) In Sec 3.4 (and somewhere earlier as well), you say:
"In case multiple PvD Options are found in a given RA, hosts MUST
   ignore all but the first PvD Option."
Why is that restriction actually needed? I mean given you can send multiple RA
from the same source address with each an PvD Option with either different of
the same ID, would it be so bad to have multiple PvD Option in the same RA?

2) As this document refers to draft-kline-mif-mpvd-api-reqs, is there any plan
to update and publish this doc? However, this draft anyway "only" talk about
API requirement, but I guess some network signalling would also be needed...?
Is there any additional work?

P.S.: The shepherd writ-up seems a bit out-dated...

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Jan 2020 08:57:52 -0800

Hi Mirja,

Thanks very much for the review!

The restriction to only use one PvD option per RA is present so that clients can be explicit about which PvD is intended to be used when sending packets. The PvD's associated prefix, and thus the client local address, should be unique for any explicit PvD on a given local network.

With regards to the informational pointer to the API requirements (draft-kline-mif-mpvd-api-reqs), I don't think there's an immediate plan to update that doc. I imagine that some of the work coming out of TAPS for interface and PvD selection can supersede this in the long term. That's an area that we'll likely see built upon once we get more explicit PvDs deployed.

Thanks,
Tommy

> On Jan 20, 2020, at 9:43 AM, Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area