Re: Soliciting comments on moving drafts to WG status

[dimitri papadimitriou <[e-mail]>]

hi adrian et al.

> 1. Loose Path Re-optimization
> draft-vasseur-ccamp-loose-path-reopt-02.txt
> This draft is stable and has an implementation.
> The work is predominantly pertinent to inter-domain signaling, but could also be used
> within a domain.
> The meeting in San Diego reported relatively few as having read the draft, but no
> objection to it becoming a WG draft.

is it part of the consensus to use this as a common document for further 
work related to "re-optimization" (incl. the delivery of ubiquitous 
signaling solution decoupled from the routing topology) in this case i'd 
be fine

> 2. A Transport Network View of LMP
> draft-aboulmagd-ccamp-transport-lmp-02.txt
> There has been a bit of off-list discussion about this draft in which it has become clear
> that there are definite differences between the ASON and CCAMP uses and views of LMP. This
> is precisely what the draft is intended to expose. That is, the draft is not intended to
> unify the views of LMP, but rather to represent the two views within a single document so
> as to highlight the differences.
> In San Diego, no-one raised objections to this being a WG draft.

yes (but i'm an author)

> 3. Graceful restart
> draft-aruns-ccamp-rsvp-restart-ext-01.txt
> This draft represents a merger of two previous drafts and was created at the specific
> request of the WG in Seoul.
> There is some more editorial work to be done on the draft, but the main technical content
> appears to be stable.
> In San Diego there was some support and no opposition to this becoming a WG draft.

yes (but i'm an author)

> 4. Inter-domain Framework
> draft-farrel-ccamp-inter-domain-framework-01.txt
> ** I am principal editor. Please take any issues with this to Kireeti **
> This draft provides a framework for the multi-domain solutions work that the WG is
> chartered to address.
> In San Diego there were some questions about whether the draft should be extended to cover
> other, more complex, inter-domain functions. There was no conclusion about whether this
> should be done before or after becoming a WG draft (if it should be done at all).

yes -

a side question: why this document is entitled "inter-domain" whereas it 
"provides a framework for establishing and controlling Multiprotocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths 
(LSPs) for multi-domain networks" so clearly the scope is *multi-domain* 
there is imho some difference between "inter-domain" that relates to the 
signaling exchange between domain boundaries only while "multi" relates 
to signaling exchange from the source until the destination across 
several domains