Re: Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Peter and I just posted -05 which should address all the outstanding
issues, and creates the POSH Service Names registry with IANA: <
https://tools.ietf.org/html/draft-ietf-xmpp-posh-05 >

To answer Barry's questions:

1)  I can act as one of the designated experts for the POSH Service
Names registry.
2) I have objections for the POSH Service Names registry requiring
Expert Review or IETF Review (and is reflected in -05)


- -- 
- - m&m

Matt Miller < [email protected] >
Cisco Systems, Inc.

On 8/28/15 7:49 AM, Peter Saint-Andre - &yet wrote:
> On 8/28/15 6:05 AM, Barry Leiba wrote:
>>>> 1. Recommend URIs like
>>>> https://example.com/.well-known/posh/spice.json
>>>> 
>>>> 2. In draft-ietf-xmpp-posh, register "posh" in the well-known
>>>> URIs registry
>>>> 
>>>> 3. In draft-ietf-xmpp-posh, set up a registry for POSH
>>>> protocols
>>>> 
>>>> 4. In draft-ietf-xmpp-dna, register "xmpp-client" and
>>>> "xmpp-server" in the POSH registry
>>>> 
>>>> I offered to Matt that I can propose text for the IANA
>>>> considerations sections since I've written such text before.
>>>> I'll endeavor to draft something in the next few days.
>>> 
>>> Here is proposed text for draft-ietf-xmpp-posh...
>> 
>> Thanks, Peter; this looks good.  Two questions, inline.
>> 
>>> 9.  IANA Considerations
>>> 
>>> 9.1.  Well-Known URI
>>> 
>>> This specification registers "posh" in the Well-Known URI 
>>> Registry as defined by [RFC5785].  The completed template
>>> follows.
>>> 
>>> URI suffix:  posh
>>> 
>>> Change controller:  IETF
>>> 
>>> Specification:  [[ this document ]]
>>> 
>>> Related information:  The suffix "posh" is expected to be 
>>> followed by an additional path component consisting of a
>>> service name (say, "spice") and a file extension of ".json",
>>> resulting in a full path of, for instance,
>>> "/.well-known/posh/spice.json". Registration of service names
>>> shall be requested by developers of the relevant application
>>> protocols.
>>> 
>>> 9.2.  POSH Service Names
>>> 
>>> This document establishes a registry for POSH service names.
>> 
>> It would help IANA if you suggested where to put the registry (in
>> an existing group of registries, or in its own, new top-level
>> group).
> 
> Ah, I thought that was up to the IANA. Given that POSH service
> names are used an additional path component in well-known URIs,
> placing this registry in the Uniform Resource Identifier (URI)
> Schemes registry would make sense.
> 
>>> POSH service names are registered on the advice of one or more 
>>> Designated Experts (appointed by the IESG or their delegate).
>>> An IANA registration policy [RFC5226] of Expert Review was
>>> chosen instead of the more liberal First Come First Served to
>>> help ensure that POSH is used in appropriate ways within
>>> applications.
>> 
>> Thanks for that explanation; it helps.
>> 
>> 1. Are Peter Saint-Andre and Matt Miller willing and able to act
>> as the designated experts?  If so, I'll put that in for IESG
>> approval.
> 
> I can serve in that capacity.
> 
>> 2. Do you want expert review to also apply to IETF documents
>> (such as xmpp-dna, which would then need expert review before
>> final approval)? If not, you could use "Expert Review OR IETF
>> Review", or "Expert Review OR Standards Action".
> 
> I think "Expert Review OR IETF Review" would be fine but I'm not
> sure what Matt thinks.
> 
>> 3. It would be good to have a short paragraph or a pointer to
>> other text that gives some guidance of what "used in appropriate
>> ways" means, so the DEs (should we eventually put in someone
>> other than the authors) know what not to accept.
> 
> Matt and I will try to formulate some text. We had some more
> specific text but it wasn't quite right. The basic idea is that we
> don't want folks to be using POSH when other technologies are a
> better fit. The example we had was DNS SRV but that wasn't correct
> since the two are complementary.
> 
>>> Registration requests are to be sent to the [email protected]
>>> mailing list for review and comment, with an appropriate
>>> subject (e.g., "Request for POSH service name: example").
>>> 
>>> Before a period of 14 days has passed, the Designated Expert(s)
>>> will either approve or deny the registration request,
>>> communicating this decision both to the review list and to
>>> IANA.  Denials should include an explanation and, if
>>> applicable, suggestions as to how to make the request
>>> successful.  Registration requests that are undetermined for a
>>> period longer than 21 days can be brought to the IESG's
>>> attention (using the [email protected] mailing list) for
>>> resolution.
>>> 
>>> 9.2.1.  Registration Template
>>> 
>>> Service name:  The name requested, relative to
>>> "/.well-known/posh/"; e.g., a service name of "example" would
>>> result in a well-known URI such as
>>> "https://example.com/.well-known/posh/example.json".
>>> 
>>> Change controller:  For Standards-Track RFCs, state "IETF".  In
>>> all other cases, give the name of the responsible party.
>>> Other details (e.g., postal address, e-mail address, home page
>>> URI) may also be included.
>> 
>> Is there a reason not to make e-mail address mandatory?  IANA
>> ought to have a recorded contact point.
> 
> True. I think that's better.
> 
>>> Definition and usage:  A brief description that defines the
>>> service name and mentions where and how it is used (e.g., in
>>> the context of a particular application protocol).
>>> 
>>> Specification:  Optionally, reference to a document that
>>> specifies the service or application protocol that uses the
>>> service name, preferably including a URI that can be used to
>>> retrieve a copy of the document.  An indication of the relevant
>>> sections may also be included, but is not required.
>>> 
>>> ###
>>> 
>>> And we would need to make associated changes in
>>> draft-ietf-xmpp-dna, such as...
>>> 
>>> ###
>>> 
>>> 9.  IANA Considerations
>>> 
>>> The POSH specification [I-D.ietf-xmpp-posh] establishes a
>>> registry for POSH service names to be used in well-known URIs
>>> [RFC5785]. This specification registers two such URIs for use
>>> in XMPP: "xmpp-client" and "xmpp-server".  The completed
>>> registration templates follow.
>>> 
>>> 9.1.  POSH Service Name for xmpp-client Service
>>> 
>>> POSH service name: xmpp-client
>> 
>> This should probably match the template in the other document,
>> so either change this to "Service name" or change the template to
>> "POSH service name".
> 
> Correct.
> 
>>> Change controller: IETF
>>> 
>>> Definition and usage: Specifies the location of a POSH file 
>>> containing verification material or a reference thereto that
>>> enables a client to verify the identity of a server for a
>>> client-to-server stream in XMPP
>>> 
>>> Specification: [[ this document ]]
>>> 
>>> 9.2.  POSH Service Name for xmpp-server Service
>>> 
>>> POSH service name: xmpp-server
>>> 
>>> Change controller: IETF
>>> 
>>> Definition and usage: Specifies the location of a POSH file 
>>> containing verification material or a reference thereto that
>>> enables a server to verify the identity of a peer server for a
>>> server-to- server stream in XMPP
>>> 
>>> Specification: [[ this document ]]
>>> 
>>> ###
>>> 
>>> Matt and I have checked this approach with a few implementers
>>> and potential implementers; no one has objected yet, but if
>>> folks on the [email protected] list or elsewhere have significant
>>> concerns it would be great to hear from you. :-)
>> 
>> Barry
> 
> Thanks for the review!
> 
> Peter
> 

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJV5d1JAAoJEDWi+S0W7cO1AvkH/iHJmElKZ5XuMLx267EmBmEL
115VGo5KZX7hVtMc4SfDRhTpywK5Y6lTPEHF++RQFyaARaNMacSMo4ZrLQfy66AK
lo8I3ZmLeAWzDZ328EO1u/mHv7wFZnBwSDO3+8bQciTCn2y2qyDxKO8FgwbmMs2n
SE24M2xmrMOyGWRIySORw8orLBkqCl0JxgirjGOY2A6OtV/eaDSUTM4TdzzpfbKJ
5K5mrrr80ilzPq7xN85a85u84U5CXCmvNVW1UuaT40htTCPOXLENuYgu7A1kzA1G
IC6OLru4bWPALvsDzcVxY3TRq4hl9OGNV6teqb7FmlTc4e4uJ3hZBKQBuGWJT4M=
=CuZv
-----END PGP SIGNATURE-----