Re: Comments on draft-kong-epp-cdn-mapping-00.txt

Hi Scott,

Thanks for your comments!

> Section 5.1.1: I'd recommend including an example <check> response.
OK. I'd like to add an example in the next version or maybe in the new draft
for IDN in future.

> Section 5.1.2 and 5.1.3: All of the extension elements are described as
> optional in the text and the schema, which implies that they can all be
> omitted. That doesn't seem right - shouldn't at least one of the elements
be
> included?
Yep, you're right. That's our mistake.

> These sections don't describe any differences in the response depending on
> the domain submitted in the command. What happens if the query is for an
> OCDN?  For an SCDN?  For a TCDN?  For a VCDN?  Does it matter?  The
> example responses contain a lot of information, but without knowing what
> was queried I don't know how to interpret the examples.
In this draft, we take OCDN, SCDN, TCDN and all VCDNs as one bundle. And
each CDN from the same bundle might have the same attributes (based on our
policy). That's to say, whether or not the query if for an OCDN, SCDN, TCDN,
or VCDN, the response should be same except the <domain:name> tag.

> Section 5.2.1: Why are the <cdn:VCDNList> and <cdn:VCDN> elements
> OPTIONAL? If they're not present, there's no reason to extend the <create>
> command at all, right?  Shouldn't one of them be present?
You're right. We made a similar mistake like Section 5.1.2 and 5.1.3. Thanks
for your corrections.

> Section 5.2.2: I really think this section needs more text to explain what
> happens when a request is made to delete an OCDN, SCDN, TCDN, and VCDNs.
> Is the list of domains returned in the response a list of domains that are
being
> deleted as a result of deleting an OCDN? If so, that should be clearly
> explained.
We indeed should make more explanations in this draft. In this draft, we
take OCDN, SCDN, TCDN and all VCDNs as one bundle, as I said above, we
extend the <delete> Command to delete all CDNs of the same bundle. If a
client only wants to delete one or some VCDNs, we suggest the client uses
<update> Command (<cdn:rem> element) which is also extended by us.

> Section 5.2.3 and 5.2.4: Similar comment with OPTIONAL elements and
> processing of the different forms.
Our similar mistakes.

> In a private email exchange with Ning Kong we discussed the possibility of
this
> draft (and others like it) being revised to describe a more general
approach to
> IDN variants.  I would support that effort.
I realize that this draft which only focuses on CDNs is limited, and a more
general approach for IDNs would be more helpful. I'd like to do this work
later. Thanks a lot for your support!

Cheers,
Ning

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg