[DNSOP] SVCB ALPN value presentation format
Seciont 6.1 says:
> The presentation value of "alpn" is a comma-separated list of one or more
> "alpn-id"s. Any commas present in the protocol-id are escaped by a backslash:
>
> escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
> escaped-id = 1*(escaped-octet)
> alpn-value = escaped-id *("," escaped-id)
If I read this correctly, the presentation value is allowed to contain nulls
and control characters. This seems likely to make such records very difficult
to edit. Wouldn't it be better to require these to be encoded as \nnn?
- lc
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB ALPN value presentation format
I think there's an implementation difficulty. Consider:
1. alpn=h2 ; clear enough
2. alpn="h2" ; should be equivalent
3. alpn=\h\2 ; should also be equivalent
4. alpn=h2,h3 ; ok (two values)
5. alpn="h2","h3" ; should be equivalent
6. alpn="h2,h3"; malformed? or a single alpn value of h2,h3? or two
three-character values, "h2 and h3"?
7. alpn=h2\,h3,h4 ; how should this be parsed?
Section 2.1.1 tempts one to build the obvious implementation of using one's
existing character-string parser, and then passing the parsed character-string
to the individual handler for each key type. The alpn and ipv*hint handlers are
going to want to split that character-string on comma. That would treat #6 as
two two-character values (h2,h3). But #7 is problematic: the generic
character-string parser would remove the backslash, and then the alpn handler
would treat this as three alpn values when you probably wanted just two.
We could make a special character-string parser for alpn and ipv*hint, that
handles commas, but it feels odd to have to use a special parser just for
certain key types. However, if we must allow commas in alpn names, then we have
no choice.
Perhaps it would be clearer to simply remove the three paragraphs of section
2.1.1 beginning with "The presentation for for SvcFieldValue is..." and ending
with "...not limited to 255 characters.)". Since the previous paragraph says
"Values are in a format specific to the SvcParamKey", perhaps it would be best
to leave the description of each value format in the appropriate part of
section 6 and for section 2.1.1 to discuss only how to represent and parse
unrecognized keys.
To keep the implementation simple, the alpn value could be defined as a
comma-separated list of sequences of printing ASCII characters, with embedded
comma represented as \, backslash as \\, and all nonprinting and non-ASCII
characters reprsented as \nnn. (In other words, the full generality of
character-string, particularly double-quotes, is not needed here.
The other comma-separated value types -- ipv4hint and ipv6hint -- do not have
this difficulty; they also don't need the full generality of character-string
handling, because the individual values can contain only hex digits, periods,
and colons, so their specification and implementation can be much simpler.
And I think section 2.1.1 would be clearer if
using decimal escape codes (e.g. \255) when necessary
were replaced by
using decimal escape codes (e.g. \255) for all nonprinting and non-ASCII
characters, and using \\ to represent backslash
- lc
> On Jun 13, 2020, at 11:25, Ben Schwartz
> wrote:
>
> Larry,
>
> I think that's the intent of the current text, especially the ABNF for
> "element". If you think it's unclear, we should adjust it. Please suggest
> text!
>
> --Ben Schwartz
>
> On Sat, Jun 13, 2020, 10:53 AM Larry Campbell
> wrote:
> Seciont 6.1 says:
>
> > The presentation value of "alpn" is a comma-separated list of one or more
> > "alpn-id"s. Any commas present in the protocol-id are escaped by a
> > backslash:
> >
> > escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
> > escaped-id = 1*(escaped-octet)
> > alpn-value = escaped-id *("," escaped-id)
>
> If I read this correctly, the presentation value is allowed to contain nulls
> and control characters. This seems likely to make such records very difficult
> to edit. Wouldn't it be better to require these to be encoded as \nnn?
>
> - lc
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
This is likely to be a Fine Proposal, worthy of serious consideration, but the venue where such topics should be considered is elsewhere, in my view. I realise that explicitly opposing such WG calls for adoption is tantamount to heresy in today’s IETF, but nevertheless I must record my opposition to adoption. I believe that the IETF passed responsibility for the determination of policy regarding the DNS namespace to what we now call ICANN some decades ago, and in line with that transfer of role and responsibility such discussions should take place within the open policy forums hosted by ICANN (however torturous and dysfunctional that may be), and accepting this document within the remit of the IETF DNSOP working group is contrary to this earlier IETF action. I'm aware that this rationale for my opposition to adoption raises yet again the entire issue of the IETF’s handling .local, .onion and the Special Use names registry, but it reflects my opinion that the delineation of roles and responsibilities between ICANN and the IETF admits various interpretations, which is an unfortunate situation that in my view potentially undermines the coherence of the DNS namespace. My personal opinion of this particular situation is that proposals such as this one that consider name policies have no place in the IETF today. thanks, Geoff > On 13 Jun 2020, at 1:12 am, Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular calls for adoptions over the next few months. We are looking for > *explicit* support for adoption. > > > This starts a Call for Adoption for draft-arends-private-use-tld > > The draft is available here: > https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 26 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On Jun 13, 2020, at 17:39, Geoff Huston wrote: > > > I believe that the IETF passed responsibility for the determination of policy > regarding the DNS namespace to what we now call ICANN some decades ago, and > in line with that transfer of role and responsibility such discussions should > take place within the open policy forums hosted by ICANN (however torturous > and dysfunctional that may be), I agree with Geoff. > and accepting this document within the remit of the IETF DNSOP working group > is contrary to this earlier IETF action. It is not entirely contrary to earlier action. We told some people, like the ones who wanted .gnu not to come to us. That we “froze” handing out special domains. And then we kind of walked back on that. The clean line for IETF is to not assign names in the DNS space that is not specifically reserved for us, like .arpa. Additionally, just like I wouldn’t want 4G to start using 192.168.1.1 as requirement for some protocol, I don’t think IETF should formally squat on someone else’s namespace - even if that someone else committed to that section being “free for all”. I feel that the free for all is meant for personal or adhoc things and not for standardization in other standards bodies. I am not in favour of adoption. Paul > >> On 13 Jun 2020, at 1:12 am, Tim Wicinski wrote: >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular calls for adoptions over the next few months. We are looking for >> *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-arends-private-use-tld >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ >> >> Please review this draft to see if you think it is suitable for adoption by >> DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 26 June 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On 13 Jun 2020, at 17:39, Geoff Huston wrote: > This is likely to be a Fine Proposal, worthy of serious consideration, but > the venue where such topics should be considered is elsewhere, in my view. I > realise that explicitly opposing such WG calls for adoption is tantamount to > heresy in today’s IETF, but nevertheless I must record my opposition to > adoption. I agree that the venue for proposing new uses for parts of the namespace (with the singular exception of the ARPA domain) belongs elsewhere. However, I think there are a couple of other things to consider with respect to this particular document: 1. whether this document actually does propose a new use for part of the namespace, or whether it is simply documenting consequences of policies that already exist and which already allow a particular use; 2. whether dnsop gets to make these kinds of decisions; I rather think if there are decisions to be made, it's the IAB that should make them. I appreciate there might be conflicting opinions about both of those, but perhaps the working group is a good place to hold the conversations. Adoption does not seem like an impossible start to those discussions, given that people have put their hands up to review. Asking the IAB to review something also seems like it falls more naturally in the workflow of dealing with a document that is the product of a working group; asking the IAB to express an opinion about whether a working group should be allowed to work on something, on the other hand, seems awkward. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On Saturday, 13 June 2020 21:39:05 UTC Geoff Huston wrote: > ... > > I believe that the IETF passed responsibility for the determination of > policy regarding the DNS namespace to what we now call ICANN some decades > ago, and in line with that transfer of role and responsibility such > discussions should take place within the open policy forums hosted by ICANN > (however torturous and dysfunctional that may be), and accepting this > document within the remit of the IETF DNSOP working group is contrary to > this earlier IETF action. ... i understand, but do not share, this point of view. ietf is where protocols come from, and dns is a protocol. early on, the decision of what top-level domains to create was made outside the ietf, but recorded by iana. later on, the iana became a functions contract, currently operated by what we now call icann, who then uses a global policy process to get the global economy's input on what top level domains to create. it is for ietf to decide what to reserve directly with the iana, for the needs of protocol development. that sets the starting conditions for what icann can work with (everything not reserved by the ietf). we might imagine a new protocol, sdns, which had an extended presentation form compared to classic dns, and in which the old namespace was encapsulated under some new top level identifier (like .ietf or .iana), and which had a search list capability allowing names not found in the sdns namespace to be findable in the old namespace. none of this would depend on cooperation from iana, or from what we now call icann as the iana functions contractor. protocol development creates identifier spaces, which have reserved identifiers. to me it makes perfect sense that ietf would develop new top level identifiers for dns, and instruct iana to reserve them. icann's role in that transaction would be as iana functions operator, and their policy development process for other parts of the icann corporate mission would not be invoked. i support adoption, and will review. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
In article <8bf10121-cf4b-4341-bc40-f427a8f4b...@apnic.net> you write: >This is likely to be a Fine Proposal, worthy of serious consideration, but the >venue where such >topics should be considered is elsewhere, in my view. I realise that >explicitly opposing such WG >calls for adoption is tantamount to heresy in today’s IETF, but nevertheless I >must record my >opposition to adoption. Agreed. The proposal is technically fine but for better or worse, ICANN is in charge of the TLD namespace these days. If something else like .onion that has a technical aspect comes along, we can probably deal with that, with ICANN's tacit cooperation, but I wouldn't push it. R's, JOhn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
John, technically ICANN is only really in charge of the gTLD name space as the ccTLD one depends on the ISO 2 letter alpha code elements over which ICANN has no control. el On 2020-06-14 02:03 , John Levine wrote: > In article <8bf10121-cf4b-4341-bc40-f427a8f4b...@apnic.net> you write: >> This is likely to be a Fine Proposal, worthy of serious >> consideration, but the venue where such topics should be considered >> is elsewhere, in my view. I realise that explicitly opposing such WG >> calls for adoption is tantamount to heresy in today’s IETF, but >> nevertheless I must record my opposition to adoption. > > Agreed. The proposal is technically fine but for better or worse, > ICANN is in charge of the TLD namespace these days. > > If something else like .onion that has a technical aspect comes along, > we can probably deal with that, with ICANN's tacit cooperation, but I > wouldn't push it. > > R's, > JOhn [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;/ Sect 20 of Act No. 4 of 2019 may apply ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
technically ICANN is only really in charge of the gTLD name space as the ccTLD one depends on the ISO 2 letter alpha code elements over which ICANN has no control. I suppose this might make sense as an informational RFC about here's what is likely to happen if you squat on these names that probably will never be in the global DNS. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
