Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
Dear Benjamin, Thanks for your input. We believe that relationship between an object and an organization should be 1-to-1, one organization ID with just one role. 1-to-many is an exception for the organization extension. Indeed that is our concern, "the multiple examples may be overkill". Many thanks. Regards, Linlin Linlin Zhou From: Benjamin Kaduk Date: 2018-10-31 09:05 To: Linlin Zhou CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext Subject: Re: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT) On Tue, Oct 30, 2018 at 10:16:05AM +0800, Linlin Zhou wrote: > Dear Benjamin, > I've included my feedbacks inline and removed the clarified items. > > Regards, > Linlin > > > Linlin Zhou > > > -- > > DISCUSS: > > -- > > > Second, I am unsure of the semantics relating to role types, especially as > > they interact with the command. Various aspects of the examples > > seem to imply that it is only permitted to have at most one organization > > mapping of a given role type (i.e., one reseller, one proxy, etc.). In > > particular, the element seems to be using the role > > attribute to determine which is being changed (with the new > > value being provided in the element body), and the element is > > providing with only the role attribute and no body to identify > > a specific organization to remove. If this reading of the document is > > correct, then I would expect the limitation to be called out more clearly, > > especially as it would seem to prevent a domain owner from (e.g.) using > > multiple DNS service operators. > > [Linlin] In the normal business model, for example a domain should have one > > reseller, one registrar etc. How about adding some text like "One > > element is suggested for each role type." in the element > > description. > > I don't think that addresses my core concern (though it is probably worth > doing in its own right). > > In particular, if it is allowed by the protocol/registry to have more than > one element of a given role type, then several of the protocol > exchanges this document defines within are not fully defined in an > interoperable fashion. For example, what if I receive a > association prohibits operation". That seems reasonable to me, given that we expect this situation to be uncommon, and a combination of and should allow the desired changes to be made more precisely. > Maybe some words like "An attempt to change an organization ID with a > particular role value, when multiple IDs exist with the same role value, does > not change the object at all. A server SHOULD notify clients that object > relationships need to be checked by sending a 2305 error response code. " > > I would suggest a little more lead-in text, maybe like: It is expected to generally be the case that any given object will have at most one associated organization ID for any given role value, though the registry semantics do permit two or more associated organizations for a given role. In such cases, certain and elements may not uniquely specify an operation to perform (e.g., which of two organizations to replace via , or which of two organizations to remove via an with empty body). An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD notify clients that object relationships need to be checked by sending a 2305 error response code. Feel free to edit as you see fit; my only concern is that the expected behavior is specified, not how it is written. (In particular, given how uncommon this situation is expected to be, the multiple examples may be overkill.) -Benjamin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin, Please see my feedbacks below. Regards, Linlin Linlin Zhou > > -- > > COMMENT: > > -- > > Section 4.3 > > > >The status of the organization object after returning this response > >MUST include "pendingCreate". The server operator reviews the > >request offline, and informs the client of the outcome of the review > >either by queuing a service message for retrieval via the > >command or by using an out-of-band mechanism to inform the client of > >the request. > > > > I don't think the "either" is appropriate; the earlier text *requires* the > > service message, and allows for additional optional notification > > mechanisms. > > [Linlin] This mechanism is supported in section 2.9.2.3 of RFC5730. > > So this is a easy and convinient way to inform the clients. > > I'm saying that the choice for the server is not "do X or do Y", it's: "do > X, then either do Y or don't do Y". The word "either" here implies that it > is sometimes acceptable to not do X (where X is the queuing of the service > message). > [Linlin] In my understanding, I think the text means do X or do Y. You can > have two choices to inform the result by of EPP command or by > out-of-band actions. The following response is an example using > mechanism. Of course you can also send an email to to contact of the > organization. > The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:) > Perhaps I am misreading, but I see this text in Section 4.2 that says that the server MUST always send a service message to notify the client: Once the action has been completed, the client MUST be notified using a service message that the action has been completed and that the status of the object has changed. Other notification methods MAY be used in addition to the required service message. The text here in Section 4.3 says: The status of the organization object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the command or by using an out-of-band mechanism to inform the client of the request. which would allow either the service message, or an out-of-band mechanism, or both mechanisms used together. My issue with the document is that the document is internally inconsistent -- in Section 4.2 it says "always do X", but Section 4.3 contradicts that by saying "you could do X, or you could not do X and do Y instead". An implementor has to pick whether to believe Section 4.2 or Section 4.3, and we should not force them to make such a choice. [Linlin] I can understand your concerns now. I think I had better propose a thread and ask the author or other EPP experts for confirmation. Once I get the feedback, I'll have a response. Thank you. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] regarding adopting new documents and milestones
On Fri, Oct 19, 2018, at 15:15, James Galvin wrote: > By now you should have seen the draft agenda for IETF103. On it you > will see 8 requests for adopting new documents as working group > milestones. Note in passing that it may not be so easy, at least to search in mailboxes because the message with this agenda on October 19th has a subject of: "Preliminary agenda for IETF102 Bangkok" (wrong IETF meeting number) To simplify discussion, the documents referenced in it are (I read only 7 of them in it, point 4, I do not know which one is the 8th): https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ https://datatracker.ietf.org/doc/draft-gould-regext-login-security-policy/ https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy/ https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/ > We are asking the group to think about the following questions. > > 1. How many open milestones should we allow ourselves to have? I do not think fixing in stone any single value provide better work. We are a very small team and obviously the resources are thin. In that vain, "forbidding" people to work on a specific subject they want to work on seems counter-intuitive to me. I believe you should instead ask for each document, who is interested by it, who "pledges" to work on it, to read it, to provide feedback to authors, etc. Of course none of this is binding, but it can give rough estimates of the energy that can happen behind each document, and it is done like that in other working groups. If some documents do not get much love from the crowd it may mean that the author first need to convince the working group that there is really an interesting generic case to solve and that his proposition is open for debate and work on it. > 2. Do we want to reconsider any currently open milestones? The three not being yet submitted for publication are: draft-ietf-regext-bundling-registration draft-ietf-regext-validate draft-ietf-regext-dnsoperator-to-rrr-protocol Only the first one has an "Implementation Status" section with 2 servers and 1 client (from my reading of the section, it contains other information not really related to current implementation status). > 3. Of the 8 documents being proposed for adoption, which ones are the > priorities, i.e., the documents we want to adopt first? I think you may get as different replies to these two questions as they are participants, so that will be a difficult task. I note also the lack of many replies to your message. Anyway, as a followup of my previous message that was more generic, while trying not to just give my personal, obviously biaised opinion, I can give the following remarks that may help choosing where it is best to devote the WG energy: - some documents have not even been presented on the list; if you search by the document name in the list archives you find no mention of it whatsoever I would expect an author wishing its work to be taken into consideration by the working group makes a least an introduction. Otherwise this working group may just look like as a rubberstamping authority, appointing standards that were already written elsewhere - unfortunately being a generic problem but many documents had very low level of discussions yet, and I do not recall having seen a lot of registries, not being the one having written the document, that shared their enthousiasm or possible thinking of implementing it; this is of course difficult to jauge as it does not necessarily happen in public view on a mailing-list, but can be in part related to the Implementation Status section that is discussed in the point just following - I just looked again at all 7 to see the Implemetnation Status for them if we want to take that into account: * draft-loffredo-regext-rdap-reverse-search has it, with 1 server implementation * draft-loffredo-regext-rdap-sorting-and-paging has it, with 2 servers implementations * draft-gould-casanova-regext-unhandled-namespaces has it, with 1 client (SDK) implementation The other 4 do not have any Implementation Status data at the moment. - another axis at which you can look is wether the document clearly tackles a generic problem or instead is very specific to one use case (author and proponents are free to try exposing the use case and how much generic it is). - in the same way you can think to discriminate between documents that add new features and those that fix or enhance or better specify existing features or corner cases (for me "draft-gould-casanova-regext-unhandled-namespaces" fits in this second case) I would personnally favor first documents that have been introduced on the list by their authors with c
Re: [regext] [Ext] regarding adopting new documents and milestones
On Mon, Oct 29, 2018, at 21:21, Andrew Newton wrote: > Perhaps priority should be given to those I-Ds with running code. This is one of the point I mage in my July message: https://mailarchive.ietf.org/arch/msg/regext/DuitffLvC4Q5RR32AnN1yDEUEYg Running code is useful/needed but maybe too high a barrier for an I-D to become a working group document. It can happen during its life I guess, but more important for me would be to have at least 2 completely separate *registries* implementation, which then could be a good idea of something that was in my July message. In short, not all extensions may become used by more than one registry. As sad as it may be for registrars (if the extension solves a generic issue that happens elsewhere or could benefit elsewhere), it is the state we are in. However in that, how much of working group energy should be devoted to that, and is the Proposed Standard path really necessary? Maybe just an addition of the extension in the EPP Extension Registry should be enough? There are a lot of extensions out there and discussed, and very few recorded in the extension registry. Basically only 3 registries took the effort to add their extensions there. And as said, sometimes an extension really tailored to one use case and one registry will need a lot of work to be more generic, and various feedback about needs of proper specification and taking care of interoperability might not be so much welcome in fact. So in summary I could say that I am not in favour of hardcoding any specific number of IDs to work on, but I would advise that 1) not all extensions need to become an RFC, being a proper ID with correct structure and registration in the extension registry is already a very good step and 2) for those wanting to be an RFC and before that wishing for the working group to work on, then they should really make sure to both display that the need spans multiple registries/registrars and that the document is really open to be updated to take into account more generic cases as needed as well as various implementation enhancements that are often only discovered when implementations are done. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC?
On Tue, Oct 30, 2018, at 19:31, Mack, Justin wrote: > I see that most attributes are shared between domains in the bundle, > such as assigned nameservers. Does this mean that DS/DNSKEY information > is also shared between these domains? Not possible for DS data as the DS digest value is computed in part from the domain name. So even if using the same key to sign two domains, the DS values will be different. It is technically possible to share a given DNSKEY between multiple domains, but then it means their fate is cryptographically tied: one key compromission opens attacks to all of them. It is kind of choosing in the X.509 world if you do one certicate with X domains related or not on one side or on the other side doing X separate certificates each one with one domain. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Dear Benjamin, "A client MUST NOT alter status values set by the server." The client can set "clientLinkProhibited" but can not alter "ok". "ok" and "clientLinkProhibited" can coexist. Regards, Linlin Linlin Zhou From: Benjamin Kaduk Date: 2018-10-31 11:23 To: Linlin Zhou CC: Eric Rescorla; regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org Subject: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT) Trimming to just one potentially problematic suggestion... On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote: > > Linlin Zhou > -- > DISCUSS: > -- [...] > [Linlin] Our proposal is to add the lead-in bolded text to match the existing > EPP RFC's to the Organization mapping. There has been no issues with the > interpretation of the statuses with the EPP RFCs, so it's best to match them > as closely as possible. In section 3.4, [bold does not work super-well in text/plain mail, but https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show it] > An organization object MUST always have at least one associated status > value. Status values can be set only by the client that sponsors an > organization object and by the server on which the object resides. A > client can change the status of an organization object using the EPP > command. Each status value MAY be accompanied by a string > of human-readable text that describes the rationale for the status > applied to the object. > > A client MUST NOT alter status values set by the server. A server This seems overly zealous to the point of being harmful. For example, if a server sets the status to "ok", a client cannot replace it by clientLinkProhibited? -Benjamin > MAY alter or override status values set by a client, subject to local > server policies. The status of an object MAY change as a result of > either a client-initiated transform command or an action performed by > a server operator. > > Status values that can be added or removed by a client are prefixed > with "client". Corresponding status values that can be added or > removed by a server are prefixed with "server". The "hold" and > "terminated" status values are server-managed when the organization > has no parent identifier [Section 3.6] and otherwise MAY be client- > managed based on server policy. Status values that > do not begin with either "client" or "server" are server-managed. > > Take "clientUpdateProhibited" for example. > If status value "clientUpdateProhibited" is set by a client > then command is not allowed to perform by a client > If status value "clientUpdateProhibited" is removed by a client or a server > then no limitation of performing EPP commands > > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou wrote:
> Dear Eric,
> Please see my feedbaks below.
>
> Regards,
> Linlin
> --
> Linlin Zhou
>
> --
>>> DISCUSS:
>>> --
>>>
>>> Rich version of this review at:
>>> https://mozphab-ietf.devsvcdev.mozaws.net/D3624
>>>
>>>
>>> This DISCUSS should be easy to clear. I have noted a few points where
>>> I do not believe that the spec is sufficiently clear to implement.
>>>
>>> DETAIL
>>> S 3.4.
>>> >
>>> > o clientUpdateProhibited, serverUpdateProhibited: Requests to
>>> update
>>> > the object (other than to remove this status) MUST be rejected.
>>> >
>>> > o clientDeleteProhibited, serverDeleteProhibited: Requests to
>>> delete
>>> > the object MUST be rejected.
>>>
>>> How does access control work here? If either of these values are set,
>>> then it must be rejected?
>>> [Linlin] If you mean that clientUpdateProhibited and
>>> serverUpdateProhibited are set, these two statuses can coexist in the
>>> system. "clientUpdateProhibited" is set by the client and
>>> "serverUpdateProhibited" is set by the server.
>>>
>>>
>> That's not what I mean. What I mean is "what is the access control rule
>> that the server is supposed to apply".
>> [Linlin] The EPP statuses defined in draft-ietf-regext-org follows the
>> model used in the other EPP RFC's, including RFC 5731- RFC 5733. The
>> statuses define the command-level access control rules, where each
>> supported transform command (update and delete) includes a corresponding
>> client-settable ("client") and server-settable ("server") that prohibits
>> execution of the command by the client. The client is allowed make an
>> update only to remove the "clientUpdateProhibited" status when the
>> "clientUpdateProhibited" status is set. Client-specific access control
>> rules (e.g., sponsoring client versus non-sponsoring client) is not defined
>> by the statuses, but is up to server policy.
>>
>>
> I'm sorry, but this still isn't clear. Can you perhaps send some
> pseudocode?
> [Linlin] Our proposal is to add the lead-in bolded text to match the
> existing EPP RFC's to the Organization mapping. There has been no issues
> with the interpretation of the statuses with the EPP RFCs, so it's best to
> match them as closely as possible. In section 3.4,
>
> An organization object MUST always have at least one associated status
> value.
>
>
>
>
> *Status values can be set only by the client that sponsors an organization
> object and by the server on which the object resides. A client can change
> the status of an organization object using the EPP command. Each
> status value MAY be accompanied by a string of human-readable text that
> describes the rationale for the status applied to the object. *
>
>
>
>
>
> *A client MUST NOT alter status values set by the server. A server MAY
> alter or override status values set by a client, subject to local server
> policies. The status of an object MAY change as a result of either a
> client-initiated transform command or an action performed by a server
> operator.*
>
> Status values that can be added or removed by a client are prefixed
> with "client". Corresponding status values that can be added or
> removed by a server are prefixed with "server". The "hold" and
> "terminated" status values are server-managed when the organization
> has no parent identifier [Section 3.6] and otherwise MAY be client-
> managed based on server policy. *S**tatus values that *
> * do not begin with either "client" or "server" are server-managed.*
>
> Take "clientUpdateProhibited" for example.
> If status value "clientUpdateProhibited" is set by a client
> then command is not allowed to perform by a client
> If status value "clientUpdateProhibited" is removed by a client or a
> server
> then no limitation of performing EPP commands
>
>
I think we are talking past each other. The question I am asking is what is
the access control algorithm for changing other values depending on whether
{client,server}UpdateProhibited is set.
-Ekr
>
>>>
>>>
>>>
>>> S 4.1.2.
>>> >
>>> > o One or more elements that contain the operational
>>> > status of the organization, as defined in Section 3.4.
>>> >
>>> > o An OPTIONAL element that contains the
>>> identifier of
>>> > the parent object, as defined in Section 3.6.
>>>
>>> It's not clear to me what's really optional here, because you say
>>> above that it's up to the server but then you label some stuff here as
>>> OPTIONAL
>>> [Linlin] If this sentence makes confusion. How about changing it to "It
>>> is up to the server policy to decide
>>> what optional attributes will be returned of an organization object."
>>> or just remove it?
>>>
>>>
>> I don't know, because I don't understand the semantics you are aiming
>> for. Are the other attributes optional.
>> [L
Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Trimming to just one potentially problematic suggestion... On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote: > > Linlin Zhou > -- > DISCUSS: > -- [...] > [Linlin] Our proposal is to add the lead-in bolded text to match the existing > EPP RFC's to the Organization mapping. There has been no issues with the > interpretation of the statuses with the EPP RFCs, so it's best to match them > as closely as possible. In section 3.4, [bold does not work super-well in text/plain mail, but https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show it] > An organization object MUST always have at least one associated status > value. Status values can be set only by the client that sponsors an > organization object and by the server on which the object resides. A > client can change the status of an organization object using the EPP > command. Each status value MAY be accompanied by a string > of human-readable text that describes the rationale for the status > applied to the object. > > A client MUST NOT alter status values set by the server. A server This seems overly zealous to the point of being harmful. For example, if a server sets the status to "ok", a client cannot replace it by clientLinkProhibited? -Benjamin > MAY alter or override status values set by a client, subject to local > server policies. The status of an object MAY change as a result of > either a client-initiated transform command or an action performed by > a server operator. > > Status values that can be added or removed by a client are prefixed > with "client". Corresponding status values that can be added or > removed by a server are prefixed with "server". The "hold" and > "terminated" status values are server-managed when the organization > has no parent identifier [Section 3.6] and otherwise MAY be client- > managed based on server policy. Status values that > do not begin with either "client" or "server" are server-managed. > > Take "clientUpdateProhibited" for example. > If status value "clientUpdateProhibited" is set by a client > then command is not allowed to perform by a client > If status value "clientUpdateProhibited" is removed by a client or a server > then no limitation of performing EPP commands > > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Dear Eric,
Please see my feedbaks below.
Regards,
Linlin
Linlin Zhou
--
DISCUSS:
--
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
DETAIL
S 3.4.
>
> o clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>
> o clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are
set, these two statuses can coexist in the system. "clientUpdateProhibited" is
set by the client and "serverUpdateProhibited" is set by the server.
That's not what I mean. What I mean is "what is the access control rule that
the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model
used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define
the command-level access control rules, where each supported transform command
(update and delete) includes a corresponding client-settable ("client") and
server-settable ("server") that prohibits execution of the command by the
client. The client is allowed make an update only to remove the
"clientUpdateProhibited" status when the "clientUpdateProhibited" status is
set. Client-specific access control rules (e.g., sponsoring client versus
non-sponsoring client) is not defined by the statuses, but is up to server
policy.
I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode?
[Linlin] Our proposal is to add the lead-in bolded text to match the existing
EPP RFC's to the Organization mapping. There has been no issues with the
interpretation of the statuses with the EPP RFCs, so it's best to match them as
closely as possible. In section 3.4,
An organization object MUST always have at least one associated status
value. Status values can be set only by the client that sponsors an
organization object and by the server on which the object resides. A
client can change the status of an organization object using the EPP
command. Each status value MAY be accompanied by a string
of human-readable text that describes the rationale for the status
applied to the object.
A client MUST NOT alter status values set by the server. A server
MAY alter or override status values set by a client, subject to local
server policies. The status of an object MAY change as a result of
either a client-initiated transform command or an action performed by
a server operator.
Status values that can be added or removed by a client are prefixed
with "client". Corresponding status values that can be added or
removed by a server are prefixed with "server". The "hold" and
"terminated" status values are server-managed when the organization
has no parent identifier [Section 3.6] and otherwise MAY be client-
managed based on server policy. Status values that
do not begin with either "client" or "server" are server-managed.
Take "clientUpdateProhibited" for example.
If status value "clientUpdateProhibited" is set by a client
then command is not allowed to perform by a client
If status value "clientUpdateProhibited" is removed by a client or a server
then no limitation of performing EPP commands
S 4.1.2.
>
> o One or more elements that contain the operational
> status of the organization, as defined in Section 3.4.
>
> o An OPTIONAL element that contains the identifier of
> the parent object, as defined in Section 3.6.
It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up
to the server policy to decide
what optional attributes will be returned of an organization object." or just
remove it?
I don't know, because I don't understand the semantics you are aiming for. Are
the other attributes optional.
[Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence
"It is up to the server policy to decide what attributes will be returned of an
organization object."
Does that mean the other attributes are mandatory? If so, you need to say that.
[Linlin] Yes, thank you.
If the element can appear once, the keyword "OPTIONAL" is used to specify it as
an optional element.
If the element can appear multiple times, the word "zero" is used to specify it
as an optional element.
Other elements are mandatory.
-
Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC?
From: Mack, Justin Date: 2018-10-31 02:31 To: regext@ietf.org Subject: Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC? >Greetings REGEXT, > >What is the impact of DNSSEC on bundled domain names in this specification? > I think that there has no direct impact. >I see that most attributes are shared between domains in the bundle, >such as assigned nameservers. Does this mean that DS/DNSKEY information >is also shared between these domains? > The DNS administrator can choose whether DS/DNSKEY information can be shared or not. This document does not specify it. >As a DNS administrator, I assume I must create separate zones for each >domain in the bundle, if I want them all to resolve. In the case of (TLDs are different) LABEL.V-tld-A and LABEL.V-tld-B, you must create separated zones. In the case of (TLD is same) V-label-A.TLD and V-label-B.TLD, you can choose to create separated zones or not. >Must I share the >same Key Signing Keys (KSKs) and even Zone Signing Keys (ZSKs) between >the bundled zones? > As pointed above, The DNS administrator can choose whether DS/DNSKEY information can be shared or not. This document does not specify it. Thanks. Jiankang Yao >Thank you. >___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
On Tue, Oct 30, 2018 at 10:16:05AM +0800, Linlin Zhou wrote: > Dear Benjamin, > I've included my feedbacks inline and removed the clarified items. > > Regards, > Linlin > > > Linlin Zhou > > > -- > > DISCUSS: > > -- > > > Second, I am unsure of the semantics relating to role types, especially as > > they interact with the command. Various aspects of the examples > > seem to imply that it is only permitted to have at most one organization > > mapping of a given role type (i.e., one reseller, one proxy, etc.). In > > particular, the element seems to be using the role > > attribute to determine which is being changed (with the new > > value being provided in the element body), and the element is > > providing with only the role attribute and no body to identify > > a specific organization to remove. If this reading of the document is > > correct, then I would expect the limitation to be called out more clearly, > > especially as it would seem to prevent a domain owner from (e.g.) using > > multiple DNS service operators. > > [Linlin] In the normal business model, for example a domain should have one > > reseller, one registrar etc. How about adding some text like "One > > element is suggested for each role type." in the element > > description. > > I don't think that addresses my core concern (though it is probably worth > doing in its own right). > > In particular, if it is allowed by the protocol/registry to have more than > one element of a given role type, then several of the protocol > exchanges this document defines within are not fully defined in an > interoperable fashion. For example, what if I receive a > association prohibits operation". That seems reasonable to me, given that we expect this situation to be uncommon, and a combination of and should allow the desired changes to be made more precisely. > Maybe some words like "An attempt to change an organization ID with a > particular role value, when multiple IDs exist with the same role value, does > not change the object at all. A server SHOULD notify clients that object > relationships need to be checked by sending a 2305 error response code. " > > I would suggest a little more lead-in text, maybe like: It is expected to generally be the case that any given object will have at most one associated organization ID for any given role value, though the registry semantics do permit two or more associated organizations for a given role. In such cases, certain and elements may not uniquely specify an operation to perform (e.g., which of two organizations to replace via , or which of two organizations to remove via an with empty body). An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD notify clients that object relationships need to be checked by sending a 2305 error response code. Feel free to edit as you see fit; my only concern is that the expected behavior is specified, not how it is written. (In particular, given how uncommon this situation is expected to be, the multiple examples may be overkill.) -Benjamin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-org extensibility comments
Thank you all. Regards, Linlin Linlin Zhou From: Martin Thomson Date: 2018-10-31 06:46 To: Adam Roach CC: zhoulinlin; regext Subject: Re: [regext] draft-ietf-regext-org extensibility comments Already done. On Wed, Oct 31, 2018 at 5:11 AM Adam Roach wrote: > > Thanks, Martin. Can you follow up with IANA to let them know that your > concerns have been satisfied? > > /a > > On 10/30/18 4:54 AM, Martin Thomson wrote: > > Thanks Linlin, that helps. If these are following existing patterns, > > that works for me. > > On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou wrote: > >> Dear Martin, > >> Thank you for your review. Please see my feedbacks inline. > >> > >> Regards, > >> Linlin > >> > >> Linlin Zhou > >> > >> > >> From: Martin Thomson > >> Date: 2018-10-26 05:09 > >> To: regext > >> Subject: [regext] draft-ietf-regext-org extensibility comments > >> Hi, > >> > >> I was asked to review draft-ietf-regext-org for the XML namespace and > >> schema registries. Everything looks fine, except that I think we got > >> crossed wires somewhere in the back and forth. > >> > >> The comment I made was that certain types use xs:enumeration with a > >> set of values. Here I refer to epp-org:statusType, > >> epp-org:roleStatusType, and epp-org:contactAttrType. > >> > >> The question was whether these types were intended to be extended, or > >> whether the working group was confident that the list was exhaustive. > >> Based on the content of the lists, it doesn't appear possible that the > >> lists could be exhaustive, but maybe there are constraints in this > >> domain that ensure this is the case. > >> > >> The current structure of the schema would prevent these from ever > >> being extended [1]. The comment was then a question: does the working > >> group believe that the set of values for these > >> [Linlin] The above mentioned types have already been existed in other EPP > >> RFCs except for some unique values specified for EPP organization object. > >> As far as I know, no registrar or registry has the requirement to extend > >> these existing type values for the domain business model. Only when > >> proposal for providing a "grace period" for DNS came out, the Redemption > >> Grace Period (RGP) status values were extended in RFC3915 which defined a > >> new element in the EPP extension. Please correct me if I am wrong. > >> > >> When I asked, the response was about epp-org:roleType/type. That > >> confused me. That element is defined as xs:token and has a registry > >> associated with it, so it's clear that this is extensible. I'm asking > >> about these enumerated types. > >> [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in > >> this xml-registry are four initial values exsting in the domain > >> regitrar-registry model. If there are new roles coming out in the future, > >> we hope they can follow the IANA change control process and be registered > >> in the existing registry described in section 3 of RFC8126. The new roles > >> should be known and accepted by most people. > >> WG discussed about this registry and had some consensus on it. Please > >> refer to > >> https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. > >> > >> And a bonus question, which I would not have commented on as the > >> designated expert, but since I'm writing, I'll ask for my own > >> gratification: Why define yet another addressing format? Just in the > >> IETF we have a ton of those already. RFC 5139 (of which I'm an > >> author, for my sins), RFC 6351 (XML vCard), just to start with. > >> [Linlin] The address format in this document tries to be consistent with > >> EPP RFCs which is defined in RFC5733. And RFC5733 was updated from > >> RFC3733. I guess RFC3733 was written in 2004 and there may be no > >> relatively proper addressing format to reuse then. So the author defined a > >> format for EPP. Of course this is just my guess:) > >> > >> --Martin > >> > >> > >> [1] I guess you could say that the schema isn't normative, and it's > >> just illustrative. But that is contrary to common practice and would > >> require a LOT more text for the document to make any sense, because > >> you would end up relying much more on the text having a normative > >> description of elements. So I'm assuming here that implementations > >> will be allowed to reject inputs that fail schema validation. > >> > >> ___ > >> regext mailing list > >> regext@ietf.org > >> https://www.ietf.org/mailman/listinfo/regext > > ___ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-org extensibility comments
Already done. On Wed, Oct 31, 2018 at 5:11 AM Adam Roach wrote: > > Thanks, Martin. Can you follow up with IANA to let them know that your > concerns have been satisfied? > > /a > > On 10/30/18 4:54 AM, Martin Thomson wrote: > > Thanks Linlin, that helps. If these are following existing patterns, > > that works for me. > > On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou wrote: > >> Dear Martin, > >> Thank you for your review. Please see my feedbacks inline. > >> > >> Regards, > >> Linlin > >> > >> Linlin Zhou > >> > >> > >> From: Martin Thomson > >> Date: 2018-10-26 05:09 > >> To: regext > >> Subject: [regext] draft-ietf-regext-org extensibility comments > >> Hi, > >> > >> I was asked to review draft-ietf-regext-org for the XML namespace and > >> schema registries. Everything looks fine, except that I think we got > >> crossed wires somewhere in the back and forth. > >> > >> The comment I made was that certain types use xs:enumeration with a > >> set of values. Here I refer to epp-org:statusType, > >> epp-org:roleStatusType, and epp-org:contactAttrType. > >> > >> The question was whether these types were intended to be extended, or > >> whether the working group was confident that the list was exhaustive. > >> Based on the content of the lists, it doesn't appear possible that the > >> lists could be exhaustive, but maybe there are constraints in this > >> domain that ensure this is the case. > >> > >> The current structure of the schema would prevent these from ever > >> being extended [1]. The comment was then a question: does the working > >> group believe that the set of values for these > >> [Linlin] The above mentioned types have already been existed in other EPP > >> RFCs except for some unique values specified for EPP organization object. > >> As far as I know, no registrar or registry has the requirement to extend > >> these existing type values for the domain business model. Only when > >> proposal for providing a "grace period" for DNS came out, the Redemption > >> Grace Period (RGP) status values were extended in RFC3915 which defined a > >> new element in the EPP extension. Please correct me if I am wrong. > >> > >> When I asked, the response was about epp-org:roleType/type. That > >> confused me. That element is defined as xs:token and has a registry > >> associated with it, so it's clear that this is extensible. I'm asking > >> about these enumerated types. > >> [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in > >> this xml-registry are four initial values exsting in the domain > >> regitrar-registry model. If there are new roles coming out in the future, > >> we hope they can follow the IANA change control process and be registered > >> in the existing registry described in section 3 of RFC8126. The new roles > >> should be known and accepted by most people. > >> WG discussed about this registry and had some consensus on it. Please > >> refer to > >> https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. > >> > >> And a bonus question, which I would not have commented on as the > >> designated expert, but since I'm writing, I'll ask for my own > >> gratification: Why define yet another addressing format? Just in the > >> IETF we have a ton of those already. RFC 5139 (of which I'm an > >> author, for my sins), RFC 6351 (XML vCard), just to start with. > >> [Linlin] The address format in this document tries to be consistent with > >> EPP RFCs which is defined in RFC5733. And RFC5733 was updated from > >> RFC3733. I guess RFC3733 was written in 2004 and there may be no > >> relatively proper addressing format to reuse then. So the author defined a > >> format for EPP. Of course this is just my guess:) > >> > >> --Martin > >> > >> > >> [1] I guess you could say that the schema isn't normative, and it's > >> just illustrative. But that is contrary to common practice and would > >> require a LOT more text for the document to make any sense, because > >> you would end up relying much more on the text having a normative > >> description of elements. So I'm assuming here that implementations > >> will be allowed to reject inputs that fail schema validation. > >> > >> ___ > >> regext mailing list > >> regext@ietf.org > >> https://www.ietf.org/mailman/listinfo/regext > > ___ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC?
Greetings REGEXT, What is the impact of DNSSEC on bundled domain names in this specification? I see that most attributes are shared between domains in the bundle, such as assigned nameservers. Does this mean that DS/DNSKEY information is also shared between these domains? As a DNS administrator, I assume I must create separate zones for each domain in the bundle, if I want them all to resolve. Must I share the same Key Signing Keys (KSKs) and even Zone Signing Keys (ZSKs) between the bundled zones? Thank you. Justin Mack MarkMonitor (Apologies for the rewritten URLs below.) On 10/11/2018 03:32 AM, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Registration Protocols Extensions WG of the > IETF. > > Title : Extensible Provisioning Protocol (EPP) Domain Name > Mapping Extension for Strict Bundling Registration > Authors : Ning Kong >Jiankang Yao >Linlin Zhou >Wil Tan >Jiagui Xie > Filename: draft-ietf-regext-bundling-registration-06.txt > Pages : 24 > Date: 2018-10-11 > > Abstract: > This document describes an extension of Extensible Provisioning > Protocol (EPP) domain name mapping for the provisioning and > management of strict bundling registration of domain names. > Specified in XML, this mapping extends the EPP domain name mapping to > provide additional features required for the provisioning of bundled > domain names. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Dbundling-2Dregistration_&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=7BwGRFn-P6YyGPxct5ZKg7otvozkt2_1DjybxjRGeR0&e= > > There are also htmlized versions available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dregext-2Dbundling-2Dregistration-2D06&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=6041TLf1_Ae96JfqxwvLSaGB8ncwtR9_w-T0RcyDPDk&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dregext-2Dbundling-2Dregistration-2D06&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=95PmUhgVYQwYLfRS5qgJU1xqL4zLGt0a-tnjJU66Owo&e= > > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Dbundling-2Dregistration-2D06&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=FuWB9lzdrjpHTIA4z4xkgs2FaGdYTGMWivotrb69wdw&e= > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=nissQXXatn7ed28hWmxicAgfpuOnSoGEK187lL577FU&e= > > ___ > regext mailing list > regext@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwICAg&c=OGmtg_3SI10Cogwk-ShFiw&r=AG9XZF6h6bGkr7jkOsJt13dFth_3nZ0W8EKEBd3N1Q8&m=aFaF5o0f8sxrnIXNr-n6f34GgoarcpzONIom6hYx98M&s=-QfLw7Pg9e9yIYF1MZVjja4oOeM-dryMKDAbbiG06DM&e= ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-org extensibility comments
Thanks, Martin. Can you follow up with IANA to let them know that your concerns have been satisfied? /a On 10/30/18 4:54 AM, Martin Thomson wrote: Thanks Linlin, that helps. If these are following existing patterns, that works for me. On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou wrote: Dear Martin, Thank you for your review. Please see my feedbacks inline. Regards, Linlin Linlin Zhou From: Martin Thomson Date: 2018-10-26 05:09 To: regext Subject: [regext] draft-ietf-regext-org extensibility comments Hi, I was asked to review draft-ietf-regext-org for the XML namespace and schema registries. Everything looks fine, except that I think we got crossed wires somewhere in the back and forth. The comment I made was that certain types use xs:enumeration with a set of values. Here I refer to epp-org:statusType, epp-org:roleStatusType, and epp-org:contactAttrType. The question was whether these types were intended to be extended, or whether the working group was confident that the list was exhaustive. Based on the content of the lists, it doesn't appear possible that the lists could be exhaustive, but maybe there are constraints in this domain that ensure this is the case. The current structure of the schema would prevent these from ever being extended [1]. The comment was then a question: does the working group believe that the set of values for these [Linlin] The above mentioned types have already been existed in other EPP RFCs except for some unique values specified for EPP organization object. As far as I know, no registrar or registry has the requirement to extend these existing type values for the domain business model. Only when proposal for providing a "grace period" for DNS came out, the Redemption Grace Period (RGP) status values were extended in RFC3915 which defined a new element in the EPP extension. Please correct me if I am wrong. When I asked, the response was about epp-org:roleType/type. That confused me. That element is defined as xs:token and has a registry associated with it, so it's clear that this is extensible. I'm asking about these enumerated types. [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in this xml-registry are four initial values exsting in the domain regitrar-registry model. If there are new roles coming out in the future, we hope they can follow the IANA change control process and be registered in the existing registry described in section 3 of RFC8126. The new roles should be known and accepted by most people. WG discussed about this registry and had some consensus on it. Please refer to https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. And a bonus question, which I would not have commented on as the designated expert, but since I'm writing, I'll ask for my own gratification: Why define yet another addressing format? Just in the IETF we have a ton of those already. RFC 5139 (of which I'm an author, for my sins), RFC 6351 (XML vCard), just to start with. [Linlin] The address format in this document tries to be consistent with EPP RFCs which is defined in RFC5733. And RFC5733 was updated from RFC3733. I guess RFC3733 was written in 2004 and there may be no relatively proper addressing format to reuse then. So the author defined a format for EPP. Of course this is just my guess:) --Martin [1] I guess you could say that the schema isn't normative, and it's just illustrative. But that is contrary to common practice and would require a LOT more text for the document to make any sense, because you would end up relying much more on the text having a normative description of elements. So I'm assuming here that implementations will be allowed to reject inputs that fail schema validation. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-org extensibility comments
Thanks Linlin, that helps. If these are following existing patterns, that works for me. On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou wrote: > > Dear Martin, > Thank you for your review. Please see my feedbacks inline. > > Regards, > Linlin > > Linlin Zhou > > > From: Martin Thomson > Date: 2018-10-26 05:09 > To: regext > Subject: [regext] draft-ietf-regext-org extensibility comments > Hi, > > I was asked to review draft-ietf-regext-org for the XML namespace and > schema registries. Everything looks fine, except that I think we got > crossed wires somewhere in the back and forth. > > The comment I made was that certain types use xs:enumeration with a > set of values. Here I refer to epp-org:statusType, > epp-org:roleStatusType, and epp-org:contactAttrType. > > The question was whether these types were intended to be extended, or > whether the working group was confident that the list was exhaustive. > Based on the content of the lists, it doesn't appear possible that the > lists could be exhaustive, but maybe there are constraints in this > domain that ensure this is the case. > > The current structure of the schema would prevent these from ever > being extended [1]. The comment was then a question: does the working > group believe that the set of values for these > [Linlin] The above mentioned types have already been existed in other EPP > RFCs except for some unique values specified for EPP organization object. As > far as I know, no registrar or registry has the requirement to extend these > existing type values for the domain business model. Only when proposal for > providing a "grace period" for DNS came out, the Redemption Grace Period > (RGP) status values were extended in RFC3915 which defined a new element in > the EPP extension. Please correct me if I am wrong. > > When I asked, the response was about epp-org:roleType/type. That > confused me. That element is defined as xs:token and has a registry > associated with it, so it's clear that this is extensible. I'm asking > about these enumerated types. > [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in > this xml-registry are four initial values exsting in the domain > regitrar-registry model. If there are new roles coming out in the future, we > hope they can follow the IANA change control process and be registered in the > existing registry described in section 3 of RFC8126. The new roles should be > known and accepted by most people. > WG discussed about this registry and had some consensus on it. Please refer > to https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. > > And a bonus question, which I would not have commented on as the > designated expert, but since I'm writing, I'll ask for my own > gratification: Why define yet another addressing format? Just in the > IETF we have a ton of those already. RFC 5139 (of which I'm an > author, for my sins), RFC 6351 (XML vCard), just to start with. > [Linlin] The address format in this document tries to be consistent with EPP > RFCs which is defined in RFC5733. And RFC5733 was updated from RFC3733. I > guess RFC3733 was written in 2004 and there may be no relatively proper > addressing format to reuse then. So the author defined a format for EPP. Of > course this is just my guess:) > > --Martin > > > [1] I guess you could say that the schema isn't normative, and it's > just illustrative. But that is contrary to common practice and would > require a LOT more text for the document to make any sense, because > you would end up relying much more on the text having a normative > description of elements. So I'm assuming here that implementations > will be allowed to reject inputs that fail schema validation. > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
