Hi Lou,


On 29 Oct 2013, at 19:28, Lou Berger <lberger@labn.net> wrote:

> Authors,
> 	I have some comments on this document. Most are strictly
> editorial. Note that I'm the document shepherd, see RFC 4858 for more
> information.
> 
> - Please address my general comments on the WSON document set
> 
> - in document
>  s/Bi-Directional/Bidirectional

GM> ok

> 
> - Abstract
>  s/Such extensions are necessary/Such extensions are applicable
>  drop "bidirectional LSPs, and”
> 

GM> ok

> - Section 1
> 
>   These extensions build on previous work for the control of lambda
>   and G.709 based networks.
> 
>  Please add appropriate references.
> 
>  It seems to that it would be worth mentioning the rwa-info document
>  and the encoding document in this section.
> 
> - section 3.1
>  s/MUST/needs to
> 

GM> ok

> - Section 3.3
>  s/MAY/can
>  s/MAY/need to be
> 

GM> ok

> - Section 3.4
>  s/MAY/can
> 

GM> ok

> - section 3.5 title
>  s/Out of Scope/Optical Impairments
> 

GM> ok

> - Section 4.2:
>   To target a specific node, this section defines a WSON_Processing
>   object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
>   defined in [RSVP-RO].
> 
>   The content of this object is defined in the subsequent sections.
>   (See Section 4.3 for <RBInformation> TLV and Section 4.4 for
>   <WavelengthSelection> TLV, respectively.)
> 
> Do you mean
> 
>   To target a specific node, this section defines a WSON_Processing
>   HOP Attribute TLV which is processed according to the procedures
>   defined in [RSVP-RO].
> 
>   The content of this TLV is defined in the subsequent sections.
>   (See Section 4.3 for <RBInformation> sub-TLV and Section 4.4 for
>   <WavelengthSelection> sub-TLV, respectively.)
> 
>  if yes, also need to s/WSON Processing object/WSON Processing TLV
>  in rest of document.
> 

GM> correct interpretation, ok

> - Section 4.2
>  You need to define the Length.  Perhaps. replace the whole definition:
> OLD
> 
>   The WSON Processing object encoding is defined as:
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |            Type               |             Length            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                                                               |
>   ~                            Value                              ~
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> NEW
>  The WSON Processing carries sub-TLVs of the same format as a HOP
>  Attributes TLV, as defined in [RSVP-RO].
> 

GM> ok

> - Section 4.3. "... PathErr SHALL be generated." Which code/value?
>  Are you sure? Generally malformed messages don't result in a PathErr.
>  What is an upstream node expected to do with the PathErr?
> 
>  How should other parsing errors be handled?
> 
>  What about allocation errors?
> 

GM> We do not expect specific errror specific error processing apart from what already defined by draft-ietf-ccamp-lsp-attribute-ro. We remove the specific error generation.

> - Section 4.4
> 
>  I'm really confused by this sub-tlv.  Is it intended to be an end to
> end construct, information that is used/updated hop-by-hop, or used at
> specific hops only?  I suspect that the desire is for this to be
> communicated end to end and accessible at each hop.  If so, it looks
> like then intent is for this to be carried as a TLV in the
> LSP_ATTRIBUTES Object.  Is this correct?  If so the section needs to be
> updated accordingly.
> 

GM> yes correct, we updated the section as LSP_ATTRIBUTES

> - Section 5
> 
> I'm really not sure that this section adds anything beyond what is
> already stated in other documents/RFCs, and it doesn't match this
> documenting being a protocol specification.  I can see some informative
> value in the third paragraph.  I suggest moving just this paragraph to
> the end of section 4.3 and dropping the rest.
> 

GM> ok

> - Section 6
>  I think this section needs to be replaced.  Perhaps use the following
> which is based on draft-ietf-ccamp-gmpls-signaling-g709v3
> 
>   This document is builds on the mechanisms defined in  [RFC3473],
>   and only differs in specific information communicated. As such,
>   this document introduces no new security considerations to the
>   existing GMPLS signaling protocols. See [RFC3473], for
>   details of the supported security measures. Additionally,
>   [RFC5920] provides an overview of security vulnerabilities and
>   protection mechanisms for the GMPLS control plane.
> 

GM> ok

> - Section 7
>  This section needs a bit of work  See
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-12#section-11
> for an example.  Contact me off list if you think need help with
> specific text.
> 

GM> updated the section we’ll send you an updated copy shortly for a quick review. 

Cheers
G

> That's it on this one,
> Lou
> 
> 
> On 10/22/2013 4:34 PM, Lou Berger wrote:
>> 
>> All,
>> 	Given the recent draft submission deadline and only one comment being
>> received to date, we'd like to extend the WG more time for review.
>> 
>> These drafts represent significant work by the authors and WG, so please
>> review and let the WG know what you think (positive or negative)!
>> 
>> Please have all comments in by October 29.
>> 
>> Thank you,
>> Lou (and Deborah)
>> 
>> On 10/1/2013 12:34 PM, Lou Berger wrote:
>>> All,
>>> 
>>> This mail begins working group last call on the WSON documents.  As
>>> there are 6 documents in this set, the last call will be three weeks.
>>> The documents included in the last call are:
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>>> (Informational, IPR Disclosed)
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11
>>> (Standards Track, IPR Disclosed)
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>>> (Standards Track)
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05
>>> (Standards Track, IPR Disclosed)
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12
>>> (Standards Track, IPR Disclosed)
>>> 
>>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards
>>> Track) Also has one open issue that will need to be resolved as part of
>>> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>> 
>>> This working group last call ends on October 22.  Comments should be
>>> sent to the CCAMP mailing list.  Please remember to include the
>>> technical basis for any comments.
>>> 
>>> Positive comments, e.g., "I've reviewed this document and believe it is
>>> ready for publication", are welcome!
>>> 
>>> Please note that we're still missing some IPR statements.  Any
>>> forthcoming publication request will be delayed by late IPR
>>> statements/disclosures.
>>> 
>>> 
>>> Thank you,
>>> Lou (and Deborah)
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>> 
>>> 
>>> 
>>> 
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>> 
>> 
>> 
>>