Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling

[Lou Berger <[e-mail]>]

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

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

- 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

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

- Section 3.4
  s/MAY/can

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

- 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.

- 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].

- 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?

- 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.

- 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.

- 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.

- 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.

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>