Subject: Re: [mpls-tp] publication request for the mpls-tp framework

From: Adrian Farrel <[email-masked]>
Date: Wed, 07 Apr 2010 14:09:33 +0100

Hi Malcolm,

FYI, I have added a note to the RFC Editor in the data tracker to ensure 
that this point is not lost even if the editors fumble it.

Cheers,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 06, 2010 4:39 PM
Subject: Re: [mpls-tp] publication request for the mpls-tp framework

> Malcolm,
>
> This text will be inserted by the RFC Editor and cannot be inserted until 
> the document has been through IETF consensus.
>
> It is possible that you are asking for the insertion of a note that 
> reminds the RFC Editor to insert the text as advised on the MPLS-TP wiki. 
> That is not an unreasonable request, but it is hardly a show-stopping 
> technical issue that needs to derail the process, is it?
>
> I'm sure the authors can take a hint and fix this oversight as one of the 
> last call comments.
>
> Thanks,
> Adrian
>
>
> ----- Original Message ----- 
> From: <[email-masked]>
> To: "Loa Andersson" <[email-masked]>
> Cc: "Adrian Farrel" <[email-masked]>; "IESG Secretary" 
> <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> "Stewart Bryant" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 06, 2010 4:12 PM
> Subject: Re: [mpls-tp] publication request for the mpls-tp framework
>
>
>> Loa,
>>
>> I understand from another email that you are running the MPLS WG and IETF
>> last calls in parallel.  However, the write-up below is anticipating the
>> result of the ITU-T review of this draft.  The ITU-T have not yet
>> indicated support for the approval of this draft, this should be 
>> reflected
>> in the write-up.
>>
>> I am aware of at least one comment from the ITU-T review of the previous
>> version that has not been incorporated into the draft, so at least that
>> correction must be made before approval.
>>
>> The missing item is the boiler plate text indicating that this draft has
>> been through the IETF consensus review process.  Without that statement
>> the ITU-T could not make any normative references to this RFC.
>>
>> Regards,
>>
>> Malcolm
>>
>>
>>
>>
>> Loa Andersson <[email-masked]>
>> Sent by: [email-masked]
>> 06/04/2010 09:00 AM
>>
>> To
>> IESG Secretary <[email-masked]>, Adrian Farrel
>> <[email-masked]>, Stewart Bryant <[email-masked]>,
>> "[email-masked]" <[email-masked]>
>> cc
>>
>> Subject
>> [mpls-tp] publication request for the mpls-tp framework
>>
>>
>>
>>
>>
>>
>> IESG,
>>
>> the mpls working group request that draft-ietf-mpls-tp-framework-11
>> is published as an Informational with IETF consensus.
>>
>> Please find the shepherd write-up included.
>>
>> /Loa
>> -- 
>>
>>
>> Loa Andersson                         email: [email-masked]
>> Sr Strategy and Standards Manager            [email-masked]
>> Ericsson Inc                          phone: +46 10 717 52 13
>>                                              +46 767 72 92 13
>>
>>
>> The MPLS WG requests that:
>>   A Framework for MPLS in Transport Networks
>>   draft-ietf-mpls-tp-framework-11
>>
>> is published as an informational RFC with IETF consensus.
>>
>>
>>> (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?
>>
>> Loa Andersson is the Document Shepherd.
>> He has reviewed the document and believes it is ready to be
>> forwarded to the IESG for publication.
>>
>>> (1.b) Has the document had adequate review both from key WG members
>>>       and from key non-WG members? Does the Document Shepherd have
>>>       any concerns about the depth or breadth of the reviews that
>>>       have been performed?
>>
>> The document has been reviewed in
>> - mpls, ccamp and pwe3 working groups
>> - the ITU-T MPLS-TP Ad Hoc Team
>> - the ITU-T SG15, Q9, Q10, Q12 and Q14.
>>
>> The shephered is convinced that this is sufficient review for this
>> framework document.
>>
>>
>>> (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.
>>
>>> (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 WG has discussed those issues and has indicated
>>>       that it still wishes to advance the document, detail those
>>>       concerns here. Has an IPR disclosure related to this document
>>>       been filed? If so, please include a reference to the
>>>       disclosure and summarize the WG discussion and conclusion on
>>>       this issue.
>>
>> No such concerns. There is no IPR claim for this draft.
>>
>>
>>
>>> (1.e) How solid is the WG consensus behind this document? Does it
>>>       represent the strong concurrence of a few individuals, with
>>>       others being silent, or does the WG as a whole understand and
>>>       agree with it?
>>
>> The mpls-tp project is a joint project between IEIT and ITU-T, this
>> document
>> has been on focus when we sorted out differences between IETF and ITU-T
>> perspectives. The shepherd is not aware of any unresolved issues.
>>
>>> (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 threats or extreme discontent.
>>
>>> (1.g) Has the Document Shepherd personally verified that the
>>>       document satisfies all ID nits? (See the Internet-Drafts Checklist
>>>       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?
>>
>> Checks are almost clean. There is one instance of a 72 charaacter line,
>> this will be fixed in the update after the IETF last call.
>>
>>
>>> (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].
>>
>> References are correctly split.
>>
>>
>>> (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 suggest a
>>>       reasonable name for the new registry? See [RFC5226]. 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?
>>
>> There are no IANA actions requested by this document.
>>
>>
>>> (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?
>>
>> No such formal language.
>>
>>> (1.k) The IESG approval announcement includes a Document
>>>       Announcement Write-Up. Please provide such a Document
>>>       Announcement Write-Up? Recent examples can be found in the
>>>       "Action" announcements for approved documents. The approval
>>>       announcement contains the following sections:
>>
>> Technical Summary
>>
>> 1.1.  Motivation and Background
>>
>>   The document describes an architectural framework to use MPLS
>>   for packet-switched transport networks.  It specifies a set of
>>   protocol functions that meet the requirements in [RFC5654]. These
>>   protocol functions constitute a MPLS Transport Profile (MPLS-TP)
>>   for point-to-point transport paths.
>>   The remaining MPLS-TP functions, applicable specifically to point-to-
>>   multipoint transport paths, are outside the scope of this document.
>>
>>   Optical transport infrastructure, e.g. SONET/SDH and OTN are known to
>>   provide reliable functionality and operational simplicity. It is the
>>   intention that the set of protocol specifications produced by the
>> MPLS-TP
>>   project shall provide the same level of reliability and simplicity
>>
>>
>> Working Group Summary
>>
>>   Since the document is an output from the MPLS-TP project it is the
>>   joint output of several IETF working groups and Qustion 9, 10, 12 and
>>   14 of ITU-T SG15.
>>
>> Document Quality
>>
>> The document is well reviewed in all the groups mentioned above.
>>
>> _______________________________________________
>> mpls-tp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>>
>