Re: [CCAMP] Comments on draft-ietf-ccamp-rsvp-te-srlg-collect-07

[Lou Berger <[e-mail]>]

Matt/Authors,
    Much thanks, I think this rev addresses my comments.  Do you have
any outstanding actions/plans on the draft or do you believe it is now
ready for LC?

Thanks,
Lou

On 10/27/2014 2:14 PM, Matt Hartley (mhartley) wrote:
> Lou,
>
> v-09 has just gone out. I think we've covered all the outstanding comments from you - please let us know if that's not the case :)
>
> Cheers
>
> Matt
>
>> Oscar,
>>     Much thanks.  I expect that your next version (which addresses these
>> and any other comments, perhaps even before HI) will be ready for LC. It
>> probably would be good to review the changes with the WG in HI,
>> particularly the completely new section 1.1. to ensure consensus  --
>> perhaps even just 1 or 2 slides.
>>
>> Lou
>>
>> On 10/23/2014 12:19 PM, OSCAR GONZALEZ DE DIOS wrote:
>>> Dear Lou,
>>>
>>>         Thank you very much for the comments.
>>>
>>>         We had some changes in
>>> draft-ietf-ccamp-rsvp-te-srlg-collect-07 ready since a couple of weeks
>>> ago that we did not find time to put together and complete. We have
>>> just sent this version. Some of your comments seems are already taken
>> into account in this version. Summarizing:
>>>         - Avoiding RFC 2119 language in lower case: done! In fact, it
>>> has been reviewed that all RFC 2119 keywords are used as they are
>> supposed to.
>>>         - Section is missing handling of RRO too big: To be added in
>> next version
>>>         - Text for multiple IDs: A sentence indicating multiple SRLG
>>> Ids can be present added. Still need to add a text explaining  the
>>> conditions to include multiple Ids. However, I think the conditions
>>> fit better in the procedure section.
>>>         - Reference for CPS: Done! Added a whole paragraph explaining
>>> the collection with CPS, and reference added.
>>>         - Removing policy processing in the resv. To be added in the
>> next version.
>>>
>>>         I hope we can be soon in Last Call..
>>>
>>>
>>>         Óscar
>>>
>>> El 23/10/14 00:07, "Lou Berger" <[e-mail]> escribió:
>>>
>>>> Authors,
>>>>       I think we still have some unresolved comments from May:
>>>>
>>>>>> - you use "should not" in lower case in a few spots in this section.
>>>>>>  While I think your usage *is* correct, my experience is that
>>>>>> someone  (probably in the IESG) will tell you that these need to be
>>>>>> in upper  case at some point.  Of course, they'll be wrong, and
>>>>>> this will have  to be explained.  I suggest avoiding 2119 language
>>>>>> in lower case where  easily avoided.  How about s/should not be/is
>>>>>> not to be
>>>> The above comment also applies to "must".
>>>>
>>>> Your current of 2119 language is a bit inconsistent. I think you
>>>> should review current uses of 2119 language and ensure that such
>>>> usage is limited to (protocol) mechanisms, behavior and
>>>> interoperability.  If doesn't the language is most likely informative
>>>> in nature and should avoid 2119 conformance language.
>>>>
>>>>>> - The section is missing handling of RRO to big. Perhaps add it at
>>>>>> ~line  330.
>>>> A few of new comments:
>>>>
>>>> - The current text of section 4.1 could be read as only one ID may be
>>>> present in the SO.  you should explain under what conditions multiple
>>>> IDs are to be added.
>>>>
>>>> -  Please provide a reference for "Confidential Path message. Segment
>>>> (CPS)"
>>>>
>>>> - (should have caught this one before, i.e., is in old text) In
>>>> Section
>>>> 5.1 it looks like you are applying policy on both Path and Resv
>>>> processing ("When a node receives a Resv message ... if local policy
>>>> determines ...). Given the "SRLG Recording Rejected" PathErr required
>>>> earlier in the section, is this really needed?  Are you assuming
>>>> separate upstream/downstream policies?  (Which would seem to be
>>>> overkill.) Covering a policy change race condition, something else? I
>>>> suspect the policy processing text on resv isn't needed.
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>> ________________________________
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura, utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en virtud de
>> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>> The information contained in this transmission is privileged and
>> confidential information intended only for the use of the individual or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have received
>> this transmission in error, do not read it. Please immediately reply to
>> the sender that you have received this communication in error and then
>> delete it.
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>> destinatário, pode conter informação privilegiada ou confidencial e é
>>> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
>>> senhoria o destinatário indicado, fica notificado de que a leitura,
>>> utilização, divulgação e/ou cópia sem autorização pode estar proibida
>>> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
>>> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
>>> proceda a sua destruição
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp