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

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2014 18:07:38 -0400

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

---

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Thu, 23 Oct 2014 16:19:03 +0000

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" <[email-masked]> escribió:

>_______________________________________________
>CCAMP mailing list
>[email-masked]
>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

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Oct 2014 12:42:49 -0400

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

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 27 Oct 2014 18:14:16 +0000

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

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Oct 2014 14:22:49 -0400

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

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 28 Oct 2014 14:42:29 +0000

Lou,

I'm not aware of anything else that needs doing prior to LC. Hopefully the other authors will yell if they are :)

However, as you said earlier, it might be an idea to present the changes that we've made since Toronto before we go to LC.

Cheers

Matt

> 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
> 
> > 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
> >>
> >>> 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
> >>>         - 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.
> >>>         - Reference for CPS: Done! Added a whole paragraph
> >>> explaining the collection with CPS, and reference added.
> >>>>>> 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
> >>>> 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.
> >>>>
> >>>> 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
> >>>>
> >> 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.
> >> 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.
> >>> 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
> >>>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 28 Oct 2014 14:45:10 +0000

>I'm not aware of anything else that needs doing prior to LC. Hopefully
>the other authors will yell if they are :)
>

Hi: 

I have the same understanding.

Thanks

Regards Š Zafar

---

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Tue, 28 Oct 2014 16:49:01 +0000

Hi,

I have the very same understanding. We have addressed among the authors
all comments sent both in the mailing list and by private mails. Our
thanks to all that have dedicated their time to review the document
several times.

I agree that a discussion in Hawai will be needed to check if all the
changes are OK to go for last call. Note that the completely new section
in the introduction is just a use case of the extensions provided in the
document. So it is purely informational. When the inclusion of the text
was suggested by Dieter, among the authors we thought it was very good to
illustrate the need of the procedure. Of course, WG should decide whether
we keep the proposed text or not. At least, we think it makes no harm and
does not touch the normative section of the document.

Best Regards,

Oscar

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 28 Oct 2014 17:46:55 +0000

> does not touch the normative section of the document.

FWIW, the new section in this draft was previously part of draft-fedyk-ccamp-uni-extensions, which was one of the LSP-diversity drafts presented and extensively discussed in London. Much of the material from draft-fedyk-ccamp-uni-extensions has now been moved to draft-ietf-ccamp-lsp-diversity, but the general feeling was that the section relating to the use of SRLGs to achieve diversity was a more natural fit in draft-ietf-ccamp-rsvp-te-srlg-collect.

Cheers

Matt

> 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