Re: [regext] Update for .se extension

[Ulrich Wisser]

Hi Scott,

“documents were moved” refers to the fact that the link to the XML spec at the 
IANA page doesn’t work any longer. The “manual” link in the notes points to an 
older version.
The new link points to a summary page where we publish the XML and the manual. 
The newest manual got an update because we detected some inconsistencies in the 
IDN definitions.

/Ulrich


From: "Hollenbeck, Scott" 
Date: Wednesday, 6 November 2019 at 17:55
To: Ulrich Wisser , "epp...@ietf.org" 

Subject: RE: Update for .se extension

Thanks, Ulrich. Is a summary of the changes available? I’m not sure I 
understand what “documents were moved” refers to.

Scott

From: regext  On Behalf Of Ulrich Wisser
Sent: Wednesday, November 6, 2019 9:22 AM
To: epp...@ietf.org
Subject: [EXTERNAL] [regext] Update for .se extension


Designated experts, please consider the following update for the .se extension.

Kind Regards

/Ulrich




-BEGIN FORM-
Name of Extension:
.SE extension

Document Status:
Informational

Reference:
https://registrar.iis.se/96

Registrant Name and Email Address:
Internet Infrastructure Foundation 
hostmas...@internetstiftelsen.se

TLDs: .se .nu

IPR Disclosure: --

Status: Active

Notes: Update to reference (documents were moved)

-END FORM-

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

Re: [regext] Questions about RDAP extensions and registration at IANA, role of prefix and version

[Hollenbeck, Scott]

Patrick, my expectation is that the value registered with IANA is the exact 
value that should appear in an rdapConformance section. The purpose of these 
values is to clearly identify an associated specification, so one should be 
able to extract an identifier from an RDAP response, look it up in the IANA 
registry, find an exact match, and unambiguously identify the associated 
specification. We clearly need to clean up this part of 7483 if/when we do 
7483bis.

Scott

> -Original Message-
> From: Patrick Mevzek 
> Sent: Wednesday, November 6, 2019 1:37 PM
> To: regext@ietf.org
> Cc: Andrew Lee Newton ; Hollenbeck, Scott
> ; marc.blanc...@viagenie.ca
> Subject: [EXTERNAL] Questions about RDAP extensions and registration at
> IANA, role of prefix and version
>
> Hello,
>
> (after having written all the below, I see it is touched already by
> https://tools.ietf.org/html/draft-blanchet-regext-rdap-deployfindings-
> 05#section-2.2 for most points, so there is some overlap but still sending my
> views below, because that draft hints at just changing things in the current
> IANA registry, where I think some RFC changes are needed too) (so CCing
> the designated experts for the IANA registry, and Marc as author of the
> above draft)
>
> IANA registry at
> https://www.iana.org/assignments/rdap-extensions/rdap-
> extensions.xhtml#rdap-extensions-1
> lists extensions names.
>
> The examples in RFC7483 with lunarNic makes me think that
> * the prefix is lunarNic
> * which is what should be registered at IANA
> * the conformance list has lunarNic_level_0
> * fields have lunarNic as prefix.
>
> So "_level_0" is a kind of suffix, under control of the relevant party (of the
> namespace being registered), but is it free-form or should it be always
> _level_?
> Once "foobar" is registered at IANA, what is its owner allowed to do?
> Can it uses any of the following in rdapConformance:
> - foobar
> - foobar_0
> - foobar0
> - foobar_level_0
> - foobar_buzz
> - foobar_level_0_sublevel_42
> ?
>
> RFC7483 §4.1 goes over this without explaining it.
>
> So some observations/questions:
>
> 1) _level_0 is not the only case.
> "fred" as registered, appears in rdapConformance as "fred_version_0"
>
> So this would make me think the _level_0 syntax is not mandatory
>
> 2) some extensions do not appear used with any suffix:
> "arin_originas0" and "cidr0" as registered as such and appear as such in
> rdapConformance.
>
> However, the final 0 seems like a "version" indicator, so why "cidr0" vs
> "cidr_level_0"?
> If so, should the registration be instead for "arin_originas" and "cidr" so 
> that
> the relevant owners can "upgrade" to a later version without a new IANA
> registration?
> But if so, this creates a collision. Shouldn't the RFC mention that when you
> register X you own X_anything, not Xanything, that is make at least a _
> character mandatory after the prefix if what is used in the rdapConformance
> is not exactly the prefix?
>
> 3) kind of same case for:
> icann_rdap_response_profile_0
> icann_rdap_technical_implementation_guide_0
>
> they are used as is in rdapConformation, but shouldn't the IANA registration
> really be for the prefix, without consideration of the "version"? And they do
> not use either _level_0, _version_0, or 0 like other extensions, but now _0.
>
> Even their own specification says:
> At the time of publication,"icann_rdap_technical_implementation_guide" is
> pending registration in the IANA RDAP Extensions Registry
>
> So what was registered at IANA is not what the specification says, there is a
> "_0" difference.
>
> Again, it seems the _level_0 part is completely optional, is that the intent?
>
>
> 4) RFC 7480 says about extension prefixes: "and they
>SHOULD NOT begin with an underscore character, numerical digit, or
>the characters "xml"."
>
> I would suggest this is amended at some point in the future to reserve
> everything starting with "rdap_" to only be used by extensions defined in
> RFCs, like RFC8521 does.
> (I am not sure what is the gain by refusing "xml" as prefix, even if I do not 
> see
> it as a useful prefix either. RDAP is far more JSON than XML stuff so if we 
> had
> to restrict something "json" would have made more sense than "xml" to me,
> even if neither makes sense to me in some way here; explanations in
> RFC7480 §6 do not really convince me there)
>
>
> What do I miss for the above discussion on prefix/suffix/version?
> Are there other documents explaining in more details this prefix/version
> schema and its rules?
>
> I am not asking all the above for the beauty(?) of it, things like that have
> strong interoperability consequences and needs to be taken into account to
> properly design a client connecting to various servers, which I sadly discover
> only now as working in RDAP-land.
>
>
> PS: unrelated additional petpeeve, for here or anywhere else, any link taken
> to a "reference" but which points to a git repository, without enforcing in 
> the
> URL

Re: [regext] FW: Incompatibility between RFC 8521 and RFC 7484

[Hollenbeck, Scott]

I just submitted an errata report for this.

Scott

> -Original Message-
> From: Andrew Newton 
> Sent: Friday, October 25, 2019 10:06 AM
> To: Hollenbeck, Scott 
> Cc: p...@dotandco.com; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: Incompatibility between RFC 8521 and
> RFC 7484
>
> Yeah, if nobody cares that strongly then an errata will suffice.
> Perhaps we can do something about this in a set of bis versions of the specs
> if/when that comes about.
>
> -andy
>
> On Fri, Oct 25, 2019 at 10:05 AM Hollenbeck, Scott
>  wrote:
> >
> > There've been no other contributions to this discussion, so I'm leaning
> towards the path of least work to address the issue Patrick identified. That
> means errata for 8521 to note that the structure of the registry is based on
> the structure from 7484, but it includes the additional contact information.
> >
> > Scott
> >
> > > -Original Message-
> > > From: regext  On Behalf Of Patrick Mevzek
> > > Sent: Wednesday, October 16, 2019 2:02 AM
> > > To: regext@ietf.org
> > > Subject: [EXTERNAL] Re: [regext] FW: Incompatibility between RFC
> > > 8521 and RFC 7484
> > >
> > >
> > >
> > > On Tue, Oct 15, 2019, at 10:17, Hollenbeck, Scott wrote:
> > > > FYI, folks. Does anyone have any thoughts on the better path forward?
> > >
> > > Between:
> > > 1) Publish errata for 8521 noting that "The bootstrap service
> > > registry for the RDAP service provider space is represented using
> > > the structure specified in Section 3 of RFC 7484" should be changed
> > > to " The bootstrap service registry for the RDAP service provider
> > > space is _modeled after_ the structure specified in Section 3 of RFC
> > > 7484", or
> > >
> > > and
> > >
> > > 2) Publish errata for 8521 to change the contact stuff, and then
> > > work with IANA to remove the contact values.
> > >
> > > I think it depends on the need or not to have contact information.
> > >
> > > If needed:
> > >
> > > - then option 1 applies, but I would think you need a little more
> > > explanation than just "is _modeled after_"; this is still probably
> > > the faster solution
> > > - or contact information could be handled elsewhere in the document,
> > > with inspiration from other RDAP specifications, using "remarks",
> > > "notices" or even "links" but that would need far more changes
> > > including to 8521 and is really more a 8521-bis than an errata. Or
> > > else just considering that for any URL given it can still be used
> > > with the "help" query case, which should be enough as the first step to
> know "who" is behind a given RDAP URL.
> > >
> > > If not needed:
> > >
> > > - option 2 is better but more work. Maybe interoperability issues
> > > for anyone already implementing this RFC?
> > >
> > >
> > > I think the contact information comes because of §3.1 So it seems
> > > useful to have, but then why not say contact information is useful
> > > for all other bootstrap documents (domain, IPv4, IPv6, etc.) also?
> > > This would mean an 7484-bis, so again quite some work.
> > >
> > >
> > > What do people having implemented RFC 8521 think about that?
> > >
> > > --
> > >   Patrick Mevzek
> > >   p...@dotandco.com
> > >
> > > ___
> > > 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] Questions about RDAP extensions and registration at IANA, role of prefix and version

[Andrew Newton]

I agree with Scott. The idea is to prevent collision and provide an
easy way to lookup the spec in the IANA registry.

These are supposed to be opaque identifiers. If an extension author
wants to add their own sub-label versioning, I guess that is ok but in
my opinion they are making things more complicated than necessary.

-andy

On Thu, Nov 7, 2019 at 7:05 AM Hollenbeck, Scott
 wrote:
>
> Patrick, my expectation is that the value registered with IANA is the exact 
> value that should appear in an rdapConformance section. The purpose of these 
> values is to clearly identify an associated specification, so one should be 
> able to extract an identifier from an RDAP response, look it up in the IANA 
> registry, find an exact match, and unambiguously identify the associated 
> specification. We clearly need to clean up this part of 7483 if/when we do 
> 7483bis.
>
> Scott
>
> > -Original Message-
> > From: Patrick Mevzek 
> > Sent: Wednesday, November 6, 2019 1:37 PM
> > To: regext@ietf.org
> > Cc: Andrew Lee Newton ; Hollenbeck, Scott
> > ; marc.blanc...@viagenie.ca
> > Subject: [EXTERNAL] Questions about RDAP extensions and registration at
> > IANA, role of prefix and version
> >
> > Hello,
> >
> > (after having written all the below, I see it is touched already by
> > https://tools.ietf.org/html/draft-blanchet-regext-rdap-deployfindings-
> > 05#section-2.2 for most points, so there is some overlap but still sending 
> > my
> > views below, because that draft hints at just changing things in the current
> > IANA registry, where I think some RFC changes are needed too) (so CCing
> > the designated experts for the IANA registry, and Marc as author of the
> > above draft)
> >
> > IANA registry at
> > https://www.iana.org/assignments/rdap-extensions/rdap-
> > extensions.xhtml#rdap-extensions-1
> > lists extensions names.
> >
> > The examples in RFC7483 with lunarNic makes me think that
> > * the prefix is lunarNic
> > * which is what should be registered at IANA
> > * the conformance list has lunarNic_level_0
> > * fields have lunarNic as prefix.
> >
> > So "_level_0" is a kind of suffix, under control of the relevant party (of 
> > the
> > namespace being registered), but is it free-form or should it be always
> > _level_?
> > Once "foobar" is registered at IANA, what is its owner allowed to do?
> > Can it uses any of the following in rdapConformance:
> > - foobar
> > - foobar_0
> > - foobar0
> > - foobar_level_0
> > - foobar_buzz
> > - foobar_level_0_sublevel_42
> > ?
> >
> > RFC7483 §4.1 goes over this without explaining it.
> >
> > So some observations/questions:
> >
> > 1) _level_0 is not the only case.
> > "fred" as registered, appears in rdapConformance as "fred_version_0"
> >
> > So this would make me think the _level_0 syntax is not mandatory
> >
> > 2) some extensions do not appear used with any suffix:
> > "arin_originas0" and "cidr0" as registered as such and appear as such in
> > rdapConformance.
> >
> > However, the final 0 seems like a "version" indicator, so why "cidr0" vs
> > "cidr_level_0"?
> > If so, should the registration be instead for "arin_originas" and "cidr" so 
> > that
> > the relevant owners can "upgrade" to a later version without a new IANA
> > registration?
> > But if so, this creates a collision. Shouldn't the RFC mention that when you
> > register X you own X_anything, not Xanything, that is make at least a _
> > character mandatory after the prefix if what is used in the rdapConformance
> > is not exactly the prefix?
> >
> > 3) kind of same case for:
> > icann_rdap_response_profile_0
> > icann_rdap_technical_implementation_guide_0
> >
> > they are used as is in rdapConformation, but shouldn't the IANA registration
> > really be for the prefix, without consideration of the "version"? And they 
> > do
> > not use either _level_0, _version_0, or 0 like other extensions, but now _0.
> >
> > Even their own specification says:
> > At the time of publication,"icann_rdap_technical_implementation_guide" is
> > pending registration in the IANA RDAP Extensions Registry
> >
> > So what was registered at IANA is not what the specification says, there is 
> > a
> > "_0" difference.
> >
> > Again, it seems the _level_0 part is completely optional, is that the 
> > intent?
> >
> >
> > 4) RFC 7480 says about extension prefixes: "and they
> >SHOULD NOT begin with an underscore character, numerical digit, or
> >the characters "xml"."
> >
> > I would suggest this is amended at some point in the future to reserve
> > everything starting with "rdap_" to only be used by extensions defined in
> > RFCs, like RFC8521 does.
> > (I am not sure what is the gain by refusing "xml" as prefix, even if I do 
> > not see
> > it as a useful prefix either. RDAP is far more JSON than XML stuff so if we 
> > had
> > to restrict something "json" would have made more sense than "xml" to me,
> > even if neither makes sense to me in some way here; explanations in
> > RFC7480 §6 do not really convi

[regext] [Technical Errata Reported] RFC8521 (5896)

[RFC Errata System]

The following errata report has been submitted for RFC8521,
"Registration Data Access Protocol (RDAP) Object Tagging".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5896

--
Type: Technical
Reported by: Scott Hollenbeck 

Section: 3

Original Text
-
The bootstrap service registry for the RDAP service provider space is 
represented using the structure specified in Section 3 of RFC 7484 [RFC7484].

Corrected Text
--
The bootstrap service registry for the RDAP service provider space is based on 
the structure specified in Section 3 of RFC 7484 [RFC7484].

Notes
-
The registry structure specific in RFC 8521 includes an additional contact 
information field that does not appear in the structure defined in RFC 7484. 
So, the 8521 registry is not "represented using the structure specified in 
Section 3 of RFC 7484". It extends the structure with the addition of the 
contact field.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8521 (draft-ietf-regext-rdap-object-tag-05)
--
Title   : Registration Data Access Protocol (RDAP) Object Tagging
Publication Date: November 2018
Author(s)   : S. Hollenbeck, A. Newton
Category: BEST CURRENT PRACTICE
Source  : Registration Protocols Extensions
Area: Applications and Real-Time
Stream  : IETF
Verifying Party : IESG

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