Pete, thanks for your review. Stewart, thanks for your response. I ran out of
time to ballot on this document unfortunately.
Alissa
> On Jul 8, 2020, at 8:48 AM, Stewart Bryant <stewart.bry...@gmail.com> wrote:
>
>
>
>> On 30 Jun 2020, at 17:55, Pete Resnick <resn...@episteme.net> wrote:
>>
>> On 30 Jun 2020, at 7:24, Stewart Bryant wrote:
>>
>>>> On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker <nore...@ietf.org>
>>>> wrote:
>>>>
>>>> Minor issues:
>>>>
>>>> It is not clear to me why this is being sent for Informational instead of
>>>> Proposed Standard. The shepherd's writeup does not justify it, and in fact
>>>> the
>>>> writeup refers to the document as a "specification", which is exactly what
>>>> it
>>>> appears to be. It defines the use of SFLs, describes how they are
>>>> processed by
>>>> the endpoints, describes how they are aggregated, etc. While the document
>>>> may
>>>> not be standalone, I don't see how it's really an Informational document. I
>>>> suggest restarting the Last Call for Proposed, and if for some reason it
>>>> needs
>>>> to be Informational, it can always be downgraded after Last Call.
>>>
>>> Pete - the “tradition”...
>>
>> I hear songs from "Fiddler on the Roof" in my head...
>>
>>> ...in routing is that such documents are Informational and the detailed
>>> protocol specifications are standards (there are a couple of those in
>>> progress about to finish baking). I leave it up to our AD to pass judgement
>>> on the matter as this is a simple fix, but I don’t think the changed status
>>> is REQUIRED.
>>
>> Absolutely agreed that it is not required, but given that this does contain
>> specification, and how much less scrutiny is given to Informational document
>> as against Standards Track (see, for example, the IESG balloting rules on
>> each), Standards Track seems more sensible. But the world remains intact
>> either way.
>
> I await judgement of the IESG on the matter.
>
>>
>>>> The Security Considerations section says, "The issue noted in Section 6 is
>>>> a
>>>> security consideration." I'm not sure I understand why that is.
>>>
>>> Section 6 explains the privacy considerations, and privacy and security are
>>> close friends so I cross referenced the section rather than repeating it. I
>>> suggest that we wait to see what SECDIR wants to do before changing any
>>> text.
>
> Note removed by popular request
>
>>
>> Yes, glad to defer to SECDIR on this.
>>
>>>> Nits/editorial comments:
>>>>
>>>> Section 1: "(see Section 3)" seems unnecessary.
>
> Removed
>
>>>
>>> I can take that out on the next version, it was intended as a forward
>>> reference to a completely new contract in MPLS.
>>>
>>>> Section 3: I thought the "Consider..." construction made those paragraphs
>>>> unnecessarily wordy and a bit harder to follow.
>>>>
>>> I will reword the first two sentences para 2 of section 3 to simplify the
>>> language.
>
> As an example application of this technology, let us consider a
> pseudowire (PW) {{RFC3985}} on which it is desired to make
> packet loss measurement. Two labels, synonymous with the PW labels, are
> obtained
> from the egress terminating provider edge (T-PE). By alternating
> between these SFLs and using them in place of the PW label, the PW
> packets may be batched for counting without any impact on the PW
> forwarding behavior (note that strictly only one SFL is needed in
> this application, but that is an optimization that is a matter for
> the implementor). The method of obtaining these additional
> labels is outside the scope of this text, however,
> one control protocol that provides a method of obtaining SFLs is described in
> {{I-D.bryant-mpls-sfl-control}}.
>
> Best regards
>
> Stewart
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
