Hi Adrian, I can take care of posting (as one of the main editors).
Minor thing, current posted version is -16, so I guess this one should be -17 right? Oscar -----Mensaje original----- De: Adrian Farrel <[email protected]> Enviado el: jueves, 12 de diciembre de 2019 21:09 Para: 'Benjamin Kaduk' <[email protected]>; 'The IESG' <[email protected]> CC: [email protected]; [email protected]; [email protected] Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT) Hi Ben, In the absence of a response from the authors this last month, I'm jumping in because I want to see this published. Authors/shepherd/chairs/AD: attached is an xml file that makes these changes. I can't post it cos I'm not an author. Cheers, Adrian === > Thank you for addressing my Discuss points! Thanks for clearing. > I do have some additional comments on the -15. Perfect. I'm trying to answer them below. > Section 2.3 > > I'm still a bit concerned that the references linked from Table 4 may > not provide a clear description of what count as Traffic Parameters > for our purposes (and how they are encoded), but not in a way that I > can express more concretely. Perhaps this is made clear by some > RSVP-TE documents with which I am not familiar. Agree that it is pretty convoluted. But I just checked all of the references and they are clear how to encode the traffic parameters for each of the different technology types in RSVP-TE. And since the PCEP objects are direct copies of the RSVP-TE ones, and since they are describing the same things, I think we are safe. It's true that it's a lot of reading, but the PCE that supports one of these bandwidth types must understand the technology as well as an RSVP-TE implementation that signals one. I think we're OK on this point. > Section 2.5.1 > > root and other endpoints TLVs are the leaves. The root endpoint MUST > be the same for all END-POINTS objects. If the root endpoint is not > > I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP? This is all in the scope of a single PCEP request message for a path. So, yes, per LSP, but multiple END-POINT objects can be present on one request. So... OLD The root endpoint MUST be the same for all END-POINTS objects. NEW The root endpoint MUST be the same for all END-POINTS objects carried in a single PCEP request message. END > Section 2.5.2.5 > > with L bit cleared. At most 2 LABEL_SET TLVs MAY be present with the > O bit set, with at most one of these having the U bit set and at most > one of these having the U bit cleared. For a given U bit value, if > > This went MUST->MAY in this rev, though I think it might be fine to > just use > a lowercase "may", since the requirements language doesn't map > terribly well > to the restriction we're making. I would prefer to make this definitive. I think the language is all mixed around. How about we do: OLD At most 2 LABEL_SET TLVs MAY be present with the O bit set, with at most one of these having the U bit set and at most one of these having the U bit cleared. NEW There MUST NOT be more than two LABEL_SET TLVs present with the O bit set. If there are two LABEL_SET TLVs present, there MUST NOT be more than one with the U bit set, and there MUST NOT be more than one with the U bit cleared. END ________________________________ 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
