Re: [martini] Draft PROTO writeup for MARTINI GIN Document

[Adam Roach <[e-mail]>]

  Bernard:

Before you send this off to Gonzalo, I think we still have an open issue 
in section 7.1.1:

  Open Issue: This section needs to call out the level of support
    required of GIN systems with regards to public GRUUs.  This issue is
    being resolved on the MARTINI mailing list.



I didn't see a formal announcement of consensus on this topic on the 
mailing list, although there was a lot of traffic around September 28th 
and 29th. I think the two contenders are basically: (1) "The SSP SHOULD 
support the public GRUU mechanism described in this section", or (2)  
"The SSP MUST support the public GRUU mechanism described in this 
section, unless the SSP has other means of providing globally routable 
contact URIs."

There were some fringe opinions that don't fit into either of these 
buckets, but (from what I can see on the mailing list), none of these 
opinions were held by more than one person.

I personally think option (2) is preferable, for the reasons I've 
explained earlier on the list.

/a


On 10/10/10 13:51, Oct 10, Bernard Aboba wrote:
>
> PROTO Writeup for draft-ietf-martini-gin
>
> =================================================
>
> http://tools.ietf.org/html/draft-ietf-martini-gin
>
>    (1.a)  Who is the Document Shepherd for this document?  Has the
>
>       Document Shepherd personally reviewed this version of the document
>
>       and, in particular, does he or she believe this version is ready
>
>       for forwarding to the IESG for publication?
>
> Bernard Aboba is the document shepherd.  I have personally reviewed
>
> the document, and believe it is ready for publication as an 
> Informational RFC.
>
>    (1.b)  Has the document had adequate review both from key members of
>
>       the interested community and others?  Does the Document Shepherd
>
>       have any concerns about the depth or breadth of the reviews that
>
>       have been performed?
>
> The document has been extensively discussed on the MARTINI WG mailing 
> list.  The discussion has
>
> included representatives from both the PBX and service-provider 
> communities as well as
>
> participants in SIP Forum.  As a result, the reviews appear to have been
>
> reasonably thorough and representative.
>
>    (1.c)  Does the Document Shepherd have concerns that the document
>
>       needs more review from a particular or broader perspective, e.g.,
>
>       security, operational complexity, someone familiar with AAA,
>
>       internationalization or XML?
>
> No concerns.
>
>    (1.d)  Does the Document Shepherd have any specific concerns or
>
>       issues with this document that the Responsible Area Director
>
>       and/or the IESG should be aware of?  For example, perhaps he or
>
>       she is uncomfortable with certain parts of the document, or has
>
>       concerns whether there really is a need for it.  In any event, if
>
>       the interested community has discussed those issues and has
>
>       indicated that it still wishes to advance the document, detail
>
>       those concerns here.
>
> No concerns.
>
>    (1.e)  How solid is the consensus of the interested community behind
>
>       this document?  Does it represent the strong concurrence of a few
>
>       individuals, with others being silent, or does the interested
>
>       community as a whole understand and agree with it?
>
> There appears to be strong consensus behind the document, which
>
> has been evaluated against the solution requirements (and appears
>
> to meet all of them).
>
>    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>
>       discontent?  If so, please summarise the areas of conflict in
>
>       separate email messages to the Responsible Area Director.  (It
>
>       should be in a separate email because this questionnaire is
>
>       entered into the ID Tracker.)
>
> No.
>
>    (1.g)  Has the Document Shepherd personally verified that the
>
>       document satisfies all ID nits?  (See
>
>       http://www.ietf.org/ID-Checklist.html and
>
>       http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
>
>       enough; this check needs to be thorough.  Has the document met all
>
>       formal review criteria it needs to, such as the MIB Doctor, media
>
>       type and URI type reviews?
>
> IDNits are clean:
>
> idnits 2.12.05
>
> tmp/draft-ietf-martini-gin-09.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>   http://trustee.ietf.org/license-info):
>
>   
> ----------------------------------------------------------------------------
>
>      No issues found here.
>
>   Checking nits according to 
> http://www.ietf.org/id-info/1id-guidelines.txt:
>
>   
> ----------------------------------------------------------------------------
>
>      No issues found here.
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
>   
> ----------------------------------------------------------------------------
>
>      No issues found here.
>
>   Miscellaneous warnings:
>
>   
> ----------------------------------------------------------------------------
>
>   -- The document date (September 28, 2010) is 12 days in the past.  
> Is this
>
>      intentional?
>
>   Checking references for intended status: Proposed Standard
>
>   
> ----------------------------------------------------------------------------
>
>      (See RFCs 3967 and 4897 for information about using normative 
> references
>
>      to lower-maturity documents in RFCs)
>
>      No issues found here.
>
>      Summary: 0 errors (**), 0 warnings (==), 1 comment (--).
>
> --------------------------------------------------------------------------------
>
>    (1.h)  Has the document split its references into normative and
>
>       informative?  Are there normative references to documents that are
>
>       not ready for advancement or are otherwise in an unclear state?
>
>       If such normative references exist, what is the strategy for their
>
>       completion?  Are there normative references that are downward
>
>       references, as described in [RFC3967]?  If so, list these downward
>
>       references to support the Area Director in the Last Call procedure
>
>       for them [RFC3967].
>
> The references in the document have been split into normative and 
> informative.
>
> Normative references are all stable documents published as RFCs.
>
>    (1.i)  Has the Document Shepherd verified that the document IANA
>
>       consideration section exists and is consistent with the body of
>
>       the document?  If the document specifies protocol extensions, are
>
>       reservations requested in appropriate IANA registries?  Are the
>
>       IANA registries clearly identified?  If the document creates a new
>
>       registry, does it define the proposed initial contents of the
>
>       registry and an allocation procedure for future registrations?
>
>       Does it suggested a reasonable name for the new registry?  See
>
>       [I-D.narten-iana-considerations-rfc2434bis].  If the document
>
>       describes an Expert Review process has Shepherd conferred with the
>
>      Responsible Area Director so that the IESG can appoint the needed
>
>       Expert during the IESG Evaluation?
>
> The IANA Considerations section exists (section 9).   The document
>
> does not create a new registry or describe an Expert Review process.
>
>    (1.j)  Has the Document Shepherd verified that sections of the
>
>       document that are written in a formal language, such as XML code,
>
>       BNF rules, MIB definitions, etc., validate correctly in an
>
>       automated checker?
>
> Not applicable.
>
>    (1.k)  The IESG approval announcement includes a Document
>
>       Announcement Write-Up.  Please provide such a Document
>
>       Announcement Writeup?  Recent examples can be found in the
>
>       "Action" announcements for approved documents.  The approval
>
>       announcement contains the following sections:
>
>       Technical Summary
>
> This document defines a mechanism by which a SIP server acting as a
> traditional Private Branch Exchange (SIP-PBX) can register with a SIP
> Service Provider (SSP) to receive phone calls for UAs designated by
> phone numbers.  The mechanism requires that the multiple AoRs being
> registered are each globally unique, which is the case for fully qualified
> AoRs representing E.164 numbers.
>
>       Working Group Summary
>
> Since this document relates to the registration of multiple AoRs in
> a single exchange, much of the discussion centered around the
> implications and limitations of the scheme.  In particular, there
> was extensive discussion on potential requirements for globally
> reachable contact URIs, as well as the circumstances under
> which the multiple AoRs being registered would each be globally
> unique.  Although the globally unique AoR requirement can be
> met for email-style URIs as well as URIs representing E.164
> numbers, this document chooses to focus on URIs representing
> E.164 numbers only.
>
>       Document Quality
>
> The document has been reviewed by participants within the IETF MARTINI 
> WG, including SIP
>
> service providers as well as representatives from the PBX vendor 
> community.  It has gone
>
> through MARTINI WG last call.
>
>       Personnel
>
> Bernard Aboba is the document shepherd for this document.
>
> Gonzalo Camarillo is the responsible AD.
>
>
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini