Re: [regext] AD review of draft-ietf-regext-rfc7482bis-02

2021-01-26 Thread Hollenbeck, Scott 
> -Original Message-
> From: Barry Leiba 
> Sent: Monday, January 25, 2021 4:25 PM
> To: draft-ietf-regext-rfc7482bis@ietf.org
> Cc: regext 
> Subject: [EXTERNAL] AD review of draft-ietf-regext-rfc7482bis-02
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Hi, all.  This is ready to go into last call, and I'll do that as soon as I'm 
> done
> reviewing 7483bis.  Only one comment (and it applies to both documents) is
> that you should please use the new BCP 14 boilerplate and add a normative
> reference to RFC 8147.

Ack, and thanks. You do mean 8174, right?

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] AD review of draft-ietf-regext-rfc7482bis-02

2021-01-26 Thread Barry Leiba 
Of course, yes, 8174.  My fingers had a light bout of dylsexia, so it seesm.

b

On Tue, Jan 26, 2021 at 7:42 AM Hollenbeck, Scott 
wrote:

> > -Original Message-
> > From: Barry Leiba 
> > Sent: Monday, January 25, 2021 4:25 PM
> > To: draft-ietf-regext-rfc7482bis@ietf.org
> > Cc: regext 
> > Subject: [EXTERNAL] AD review of draft-ietf-regext-rfc7482bis-02
> >
> > Caution: This email originated from outside the organization. Do not
> click links
> > or open attachments unless you recognize the sender and know the content
> > is safe.
> >
> > Hi, all.  This is ready to go into last call, and I'll do that as soon
> as I'm done
> > reviewing 7483bis.  Only one comment (and it applies to both documents)
> is
> > that you should please use the new BCP 14 boilerplate and add a normative
> > reference to RFC 8147.
>
> Ack, and thanks. You do mean 8174, right?
>
> Scott
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

2021-01-26 Thread Martin Casanova 
Barry

Thanks for your review. Since James Gould is the main author of this
draft I think it is better if he comments your suggestions.
Nevertheless I try to answer your question about section 3.

RFC 5730 chapter 2.6:

Zero or more OPTIONAL  elements that can be used to
 provide additional error diagnostic information, including:

 *  A  element that identifies a client-provided element
(including XML tag and value) that caused a server error
condition.


The  element according to RFC 5730 should be used in a server
error condition. Therefore in responses that have normally a result code
starting with 2xxx like

 2004"Parameter value range error"
 2005"Parameter value syntax error"
 2306"Parameter value policy error"

The intent of  draft-ietf-regext-unhandled-namespaces is to redefine the
purpose of the  element to be used with successful command
(result code 1xxx) and to use it to return content of the response that
normally would be omitted because the client did not announce the
extension/namespace at client login.
Maybe

XML processing of the  element is
   disabled in [RFC5730],

could be formulated more precisely explain this eg:

'The original usage of  defined in RFC 5730 returning
client-provded elements in unsuccessful command is redefined by this
document as to return unhanlded namespaces'.. or so..

Thanks again and stay healthy.

Martin Casanova




On 22.01.21 20:22, Barry Leiba wrote:
> Thanks for the publication request for this document; here's my AD
> review.  None of this is a big thing, just some easy tweaks.  It will
> need a revised I-D, though, so I'll set the substate accordingly.
>
> The Abstract goes into more detail than the Abstract needs to or
> should.  The Introduction correctly explains the details, but the
> Abstract shouldn’t.  I suggest trimming the Abstract thus (but please
> do use your judgment on this):
>
> NEW
>The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
>includes a method for the client and server to determine the objects
>to be managed during a session and the object extensions to be used
>during a session.  The services are identified using namespace URIs,
>and an “unhandled namespace” is one that is associated with a service
>not supported by the client in question.  This document defines an
>operational practice that enables the server to return information
>associated with unhandled namespace URIs that is compliant with the
>negotiated services defined in RFC 5730.
> END
>
> — Section 1.1 —
>
> Please use the new BCP 14 boilerplate and add a normative reference to RFC 
> 8174.
>
>Indentation and white space in examples are provided only to
>illustrate element relationships and are not a REQUIRED feature of
>this protocol.
>
> That’s not a BCP 14 usage of “required”, and should be in lower case.
>
> — Section 3 —
>
>XML processing of the  element is
>disabled in [RFC5730],
>
> Where and how is this stated in 5730?  I can’t find anything, but
> perhaps I just don’t know where to look.  It would be good to add a
> section number to the citation.
>
> — Section 8.2 —
>
> Please change the Registrant Name to “IETF” (you may leave the email
> address as it is), as that’s how the IESG prefers to designate it (the
> IETF
>
> — Section 10 —
>
> Nit: make it “This document does not provide…”
>
> That aside, I would be surprised if we don’t get some pushback about
> this section, so maybe we should think about it a bit more.  I accept
> that there are likely no security issues raised by this operational
> practice, but it would be good to address that more directly.  This is
> proposing that a server return information to a client that indicates
> that the server believes a particular service is not supported by the
> client.  You should call that out, and consider whether that could
> expose anything that could be used by an attacker — or that could be
> misused to create an attack.  Or, could an attacker do something
> related to this practice that would allow it to disrupt some
> legitimate communication?
>
> The answer to all of that might be “no”, but it would be good to… as
> we used to say in school, show your work.
>

-- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

2021-01-26 Thread Gould, James 
Barry,

I respond to your feedback embedded below.  I saw Martin's reply that I 
reference for section 3 below.  I will publish 
draft-ietf-regext-unhandled-namespaces-07 once these items are agreed to.  Let 
me know if you agree with the proposed updates below or if you have any 
additional proposed changes.

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 1/22/21, 2:23 PM, "Barry Leiba"  wrote:

Thanks for the publication request for this document; here's my AD
review.  None of this is a big thing, just some easy tweaks.  It will
need a revised I-D, though, so I'll set the substate accordingly.

The Abstract goes into more detail than the Abstract needs to or
should.  The Introduction correctly explains the details, but the
Abstract shouldn’t.  I suggest trimming the Abstract thus (but please
do use your judgment on this):

NEW
   The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
   includes a method for the client and server to determine the objects
   to be managed during a session and the object extensions to be used
   during a session.  The services are identified using namespace URIs,
   and an “unhandled namespace” is one that is associated with a service
   not supported by the client in question.  This document defines an
   operational practice that enables the server to return information
   associated with unhandled namespace URIs that is compliant with the
   negotiated services defined in RFC 5730.
END

JG - I took your proposal with one tweak in removing "in question" from "client 
in question". 

— Section 1.1 —

Please use the new BCP 14 boilerplate and add a normative reference to RFC 
8174.

   Indentation and white space in examples are provided only to
   illustrate element relationships and are not a REQUIRED feature of
   this protocol.

That’s not a BCP 14 usage of “required”, and should be in lower case.

JG - Done

— Section 3 —

   XML processing of the  element is
   disabled in [RFC5730],

Where and how is this stated in 5730?  I can’t find anything, but
perhaps I just don’t know where to look.  It would be good to add a
section number to the citation.

JG - This is not stated in the text of RFC5730, but is based on the XML schema 
use of the processContents="skip" attribute of the "errValueType" type in 
section 4.1 "Base Schema".  How about revising this to read "XML processing of 
the  element is disabled by the XML schema in [RFC5730]".  Martin 
provided more context around the use of the  element, but I believe that 
we can provide clarity around the statement with the reference to the XML 
schema.  Does adding this help clarify the statement?  

— Section 8.2 —

Please change the Registrant Name to “IETF” (you may leave the email
address as it is), as that’s how the IESG prefers to designate it (the
IETF

JG - Done

— Section 10 —

Nit: make it “This document does not provide…”

JG - Done

That aside, I would be surprised if we don’t get some pushback about
this section, so maybe we should think about it a bit more.  I accept
that there are likely no security issues raised by this operational
practice, but it would be good to address that more directly.  This is
proposing that a server return information to a client that indicates
that the server believes a particular service is not supported by the
client.  You should call that out, and consider whether that could
expose anything that could be used by an attacker — or that could be
misused to create an attack.  Or, could an attacker do something
related to this practice that would allow it to disrupt some
legitimate communication?

The answer to all of that might be “no”, but it would be good to… as
we used to say in school, show your work.

JG - Yes, the quick answer is that I don't see the server using this as a 
source for an attack, but we can add a consideration to help mitigate it.  I 
can add the sentence "Since the unhandled namespace context is XML that is not 
processed in the first pass by the XML parser, the client SHOULD consider 
validating the XML when the content is processed to protect against the 
inclusion of malicious content."  The content is not processed by a client that 
doesn't support the service, where the  element provides a signal of 
the lack of client support along with the XML content that is initially 
unprocessed.  If the client does decide to process the XML content 
systematically, the additional sentence can provide guidance to not open up a 
security hole.  Do you believe this will help?  Do you have any additional 
recommended text?  

-- 
Barry

___
regext mailing list
regext@ietf.org
ht

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

2021-01-26 Thread Barry Leiba 
All good, and thanks.  Go ahead and post a revised I-D when you're ready.


>> The answer to all of that might be “no”, but it would be good to… as
>> we used to say in school, show your work.
>
> Yes, the quick answer is that I don't see the server using this as a
> source for an attack, but we can add a consideration to help mitigate
> it.  I can add the sentence "Since the unhandled namespace context is
> XML that is not processed in the first pass by the XML parser, the
> client SHOULD consider validating the XML when the content is
> processed to protect against the inclusion of malicious content."  The
> content is not processed by a client that doesn't support the service,
> where the  element provides a signal of the lack of client
> support along with the XML content that is initially unprocessed.  If
> the client does decide to process the XML content systematically, the
> additional sentence can provide guidance to not open up a security
> hole.  Do you believe this will help?  Do you have any additional
> recommended text?

I have nothing further to recommend, and I do think it will help -- if
at least to show that it was thought about, and that the "nothing new
here" statement isn't just perfunctory.  Thanks.

Barry

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-unhandled-namespaces-07.txt

2021-01-26 Thread internet-drafts 


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) Unhandled 
Namespaces
Authors : James Gould
  Martin Casanova
Filename: draft-ietf-regext-unhandled-namespaces-07.txt
Pages   : 22
Date: 2021-01-26

Abstract:
   The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
   includes a method for the client and server to determine the objects
   to be managed during a session and the object extensions to be used
   during a session.  The services are identified using namespace URIs,
   and an "unhandled namespace" is one that is associated with a service
   not supported by the client.  This document defines an operational
   practice that enables the server to return information associated
   with unhandled namespace URIs that is compliant with the negotiated
   services defined in RFC 5730.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-unhandled-namespaces-07.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-unhandled-namespaces-07


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:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

2021-01-26 Thread Gould, James 
Barry,

Done, draft-ietf-regext-unhandled-namespaces-07 has been posted.  Let us know 
if you have any additional feedback.

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 1/26/21, 1:47 PM, "Barry Leiba"  wrote:


All good, and thanks.  Go ahead and post a revised I-D when you're ready.


>> The answer to all of that might be “no”, but it would be good to… as
>> we used to say in school, show your work.
>
> Yes, the quick answer is that I don't see the server using this as a
> source for an attack, but we can add a consideration to help mitigate
> it.  I can add the sentence "Since the unhandled namespace context is
> XML that is not processed in the first pass by the XML parser, the
> client SHOULD consider validating the XML when the content is
> processed to protect against the inclusion of malicious content."  The
> content is not processed by a client that doesn't support the service,
> where the  element provides a signal of the lack of client
> support along with the XML content that is initially unprocessed.  If
> the client does decide to process the XML content systematically, the
> additional sentence can provide guidance to not open up a security
> hole.  Do you believe this will help?  Do you have any additional
> recommended text?

I have nothing further to recommend, and I do think it will help -- if
at least to show that it was thought about, and that the "nothing new
here" statement isn't just perfunctory.  Thanks.

Barry

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Last Call: (Extensible Provisioning Protocol (EPP) Unhandled Namespaces) to Proposed Standard

2021-01-26 Thread The IESG 


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) Unhandled Namespaces'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
   includes a method for the client and server to determine the objects
   to be managed during a session and the object extensions to be used
   during a session.  The services are identified using namespace URIs,
   and an "unhandled namespace" is one that is associated with a service
   not supported by the client.  This document defines an operational
   practice that enables the server to return information associated
   with unhandled namespace URIs that is compliant with the negotiated
   services defined in RFC 5730.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/



No IPR declarations have been submitted directly on this I-D.





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

2021-01-26 Thread Quoc@registry.godaddy 
Hi Antoin and all,

I apologies for my late contribution on this subject, as a backend that has 
implemented (albeit an older draft) of the maintenance draft, I have the 
following to share on the list of actions posted by James Gould on 2021-01-15 
(that would be my local date in Melbourne, Australia).


  1.  Need for a formatted HTML description, since notices currently include 
formatted HTML content.

Quoc: I don’t think this is needed, I see the intent to be a machine to machine 
notification, the presence of an optional URI (maint:detail) provides details 
that are more human friendly which the client server may pass onto their users 
as needed. I assume this comment is in relation to HTML formatted email notices 
sent to Registrars, if this assumption is true, I don’t think that making the 
maintenance object be like for like with an email notice is needed. Often HTML 
formatted email is a decision to format the presentation of the information so 
that it looks “nice” and is formatted to corporate standards. Another use case 
for this to not be required is that in some emails it contains attachments, 
there’s no way in replicating that in the maintenance object.

  1.  How to signal the maintenance of an entire system versus the maintenance 
of an individual or set of TLDs on the system

Quoc: I find the use of maint:impact in combination of maint:tld as reasonable. 
Our system supports multiple TLDs from a single end point and so we use this 
combination as needed. For instance if there was maintenance specific for .biz 
we would only report BIZ in the maint:tld list. Also what I would like to share 
is what is being referred to as maintenance? Things of a technical nature is 
pretty straight forward, e.g. software upgrade, so TLDs are hosted on a single 
system then when there is an upgrade to the backend then maintenance will be 
performed on ALL TLDs. However what if there is an UPDATE to a TLD which is not 
software related but more business driven. E.g. if there is a TLD registration 
policy update, this I don’t see as qualifying as a maintenance but today there 
would be an email notification to all Registrars with access to the TLD being 
updated. In spirit of simplicity I only would consider maintenance of a 
technical nature in the maintenance object.

  1.  Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to 
maintenance) notices and maintenance end notices.

Quoc: Noting that this is a suggestion for a "courtesy", I find this 
unnecessary as the consumer here is a machine. So when a maintenance object is 
created only single object is created and it’s expected that the client server 
stores the date and time reported and set their own reminders. If this was an 
email notification for humans to read then that’s a different matter (not to 
say that reminders are not needed). Of course if the WG thinks it’s good to 
send out service messages at a 2 week, 1 week, 2 day and 1 day before the 
maintenance then I’ll be OK to implement as a courtesy however I would suggest 
that clients that read the message implement a scaling interval that they are 
comfortable with.

Regards


Quoc Pham
GoDaddy Registry | Senior Product Manager
[https://email-sig.gd-resources.net/img/godaddy-registry-logo-outline.png]
+61398663710
Level 8, 10 Queens Road
Melbourne, Victoria, Australia
3004
quoc@registry.godaddy

From: regext  On Behalf Of Antoin Verschuren
Sent: Tuesday, January 26, 2021 1:40 AM
To: regext@ietf.org
Subject: Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-09

Notice: This email is from an external sender.


This WGLC formally ended last week.
The chairs are concerned that there are still outstanding comments to be 
addressed.
Also, apart from from the authors, we did not see any support from other WG 
participants.

We will take back this document into the working group to get this support and 
to address the outstanding comments.

Regards

Jim and Antoin



Op 18 jan. 2021, om 15:59 heeft Antoin Verschuren 
mailto:i...@antoin.nl>> het volgende geschreven:

James,

Just to note for the record, I was surprised by your surprise ;-), since the 
document authors asked us for a WGLC  in December. We waited for January 4th 
after version 09 was published that addressed your previous feedback. We were 
aware that the discussion on the mailing list took place with your previous 
comments.

The WGLC will end today, but seeing your new comments, we don’t think this is 
ready to be submitted to the IESG just yet.
A formal closure of this WGLC will follow later this week, but so far I can see 
no consensus yet, and work still needs to be done.

regards,

Antoin


Op 7 jan. 2021, om 14:39 heeft Gould, James 
mailto:jgould=40verisign@dmarc.ietf.org>>
 het volgende geschreven:

Antoin,

I was surprised to see draft-ietf-regext-epp-registry-maintenance move to WGLC 
based on the work that has been progressing on the mailing list, so at t