Re: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document

[Loa Andersson <[e-mail]>]

Fokks,

<chair hat off>

I'd prefer that the hard values before going to poll to make
it a working group document;

<chair hat on>

but as a working group chair I would not require that any authors
make any changes to any non-working group documents.

There are things that needs to be fixed before starting the poll;
a perfect IANA section is not one of them. Updating the IANA sections
as part of what we do to working group documents; I guess there are
numerous author groups that can verify that that happens prior to
the request publication.

I see no reason to treat drfat-lim- differently.

/Loa

On 2013-06-07 15:49, t.petch wrote:
> ----- Original Message -----
> From: "Eric Gray" <[e-mail]>
> To: "Loa Andersson" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Sent: Thursday, June 06, 2013 3:17 PM
>> Loa,
>>
>> Mostly good points.  However, it is frequently the case that the WG
> chairs require
>> certain changes to be made - other than the obvious "name change" for
> the draft - based on
>> comments made during the polling for adoption.
>>
>> This is by no means unusual.
>
> Eric
>
> I think otherwise.  My experience in the IETF is that when an I-D is
> adopted by a WG, then the only change is to the title.  Often the
> instruction from the WG Chair explicitly spells this out.
>
> Of course, changes can be made beforehand, to smooth the adoption, and
> after, under the control of the WG, but at adoption, I think best not;
> what might be uncontentious to one party might be a reason for changing
> their mind to another, so only changing the name obviates that.
>
> I agree that the IANA Considerations need work.  It would be better IMO
> if the authors took out the 'hard' values beforehand.  If I had to
> express an opinion, then it would be not to adopt until all those values
> had been removed (which is not exactly a technical reason).
>
> Tom Petch
>
>> This is what I am suggesting needs to be done in this case - i.e. - if
> the draft is adopted
>> by the WG, it should not be published as a WG draft without fixing the
> IANA section.
>>
>> As to the point you make about the faults in the IANA section being a
> good reason to
>> adopt the draft as a working group draft - well - sorry but that is
> ridiculous (as I am sure you
>> will realize if you think about it).  If that were true, the easiest
> way to get any draft adopted
>> by the WG would be to abuse the IANA Considerations section.
>>
>> We would clearly be risking setting a dangerous precedent by even
> suggesting this.
>>
>> What should instead be the case is that any private draft that expects
> to use an IANA
>> registry that is "owned" by an IETF working group MUST use the "tbd-#"
> style variables or it
>> can be explicitly removed from the ID repository based on a request
> from the chair(s) of that
>> working group.
>>
>> --
>> Eric
>>
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Thursday, June 06, 2013 5:22 AM
>> To: Eric Gray
>> Cc: [e-mail]; [e-mail];
> [e-mail]
>> Subject: Re: [mpls] Poll to see if we have consensus to make
> draft-lim-mpls-proxy-lsp-ping an MPLS working group document
>> Importance: High
>>
>> Eric,
>>
>> You point at an issue that we need to resolve.
>>
>>   From a working group point of view there is no "early allocation"
> made for draft-lim-mpls-proxy-lsp-ping; as a matter of fact there can't
> be any early allocation made, since these can be made only to working
> group documents. RFC 4020 says "The processes described below assume
> that the document in question is the product of an IETF Working Group."
>>
>> There is a practice among many authors to "propose" values in the IANA
> section. For new registries this is at least semi-encouraged.
>>
>> For existing registries this practice is most of the time not harmful,
> but could create problems if the proposed values are actually used in
> implementations. It is RECOMMENDED that our documents use the tbd-1
> style variables.
>>
>> The problem here is the definition of "our documents", strictly
> draft-lim-mpls-proxy-lsp-ping does really meet the criteria to be one of
> "our documents" until it actually is accepted as a working group
> document - when the working group take over the revision control.
>>
>> The working group can't tell the authors what to do with the document,
> until it becomes a working group document! My conclusion is that the
> issues on the IANA allocation you point to is a reason to making it a
> working group document.
>>
>> There are potential "clashes", both draft-lim-mpls-proxy-lsp-ping and
> draft-ietf-mpls-return-path-specified-lsp-ping are looking to assign new
> TLV Type values, it might be that the value proposed by
> draft-lim-mpls-proxy-lsp-ping (Type 22) is already assigned when we
> request publication of theis draft.
>>
>> Note: draft-lim-mpls-proxy-lsp-ping is currently in wg poll and should
>>         for the time being not be updated.
>>
>> /Loa
>>
>> On 2013-06-05 23:26, Eric Gray wrote:
>>> In addition to the previously noted issues, from discussion, it
> looks like the values "assigned"
>>> in the IANA considerations section are at least questionable at this
> point.
>>>
>>> At present, there is only one obvious clash in these assignments
> (the
>>> draft "assigns" the value "5" in the "Downstream [Mapping Address
>>> Type] Registry" and this value has already been assigned via RFC
>>> 6426).  However, the MPLS WG now has in place an early assignment
>>> process and it may be the case that other assignments have been made
> via this process and a clash will occur when these are permanently
> assigned later.
>>>
>>> As a NIT - compounding the issues in this case - two of the affected
>>> Registries are incorrectly named in the IANA section.
>>>
>>> These values should be replaced with "variables" (e.g. - TBA-1,
> TBA-2,
>>> TBA-3, etc.) before the draft is adopted as a WG draft.  Once
> adopted,
>>> the authors of this draft may then apply for early assignments via
> the existing process.
>>>
>>> --
>>> Eric
>>>
>>> -----Original Message-----
>>> From: Eric Gray
>>> Sent: Wednesday, June 05, 2013 3:02 PM
>>> To: 'Loa Andersson'; [e-mail]
>>> Cc: [e-mail];
>>> [e-mail]
>>> Subject: RE: [mpls] Poll to see if we have consensus to make
>>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document
>>>
>>> Don't support at the current time.
>>>
>>> The draft does not appear to deal reasonably with the case where a
> desired remote "Proxy LSP Ping" LSR does not support this capability.  I
> searched and the phrase "backward compatibility" is not in the full-text
> version of the draft.
>>>
>>> I also have some questions about the utility of this capability,
> given that this might - for instance - be used by an edge router to task
> other routers with "pinging" toward another edge router.  Presumably,
> this could include routers which are typically not optimized to handle
> processing of traffic such as Ping responses.
>>>
>>> This could be made very much worse if - within the context of the
> service provider network - a large number of edge LSRs were compromised
> and became agents in a DDoS attack on the service provider core network.
>>> --
>>> Eric
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Loa Andersson
>>> Sent: Thursday, May 30, 2013 12:35 PM
>>> To: [e-mail]
>>> Cc: [e-mail];
>>> [e-mail]
>>> Subject: [mpls] Poll to see if we have consensus to make
>>> draft-lim-mpls-proxy-lsp-ping an MPLS working group document
>>>
>>> Working Group,
>>>
>>> This is to start a two week poll on adopting
>>> draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document.
>>>
>>> Please send your comments (support/not support) to the mpls working
> group mailing list (mpls at ietf.org). Please give a technical
> motivation for your support/not support, especially if you think that
> the document should not be adopted as a working group document.
>>>
>>> This poll ends June 14, 2013.
>>>
>>> There are two IPR claims against this document:
>>>
>>> https://datatracker.ietf.org/ipr/778/
>>> https://datatracker.ietf.org/ipr/2087/
>>>
>>>
>>> The authors has stated on the working group mailing list that they
> are not aware of any other IPR claims against this draft.
>>> However if you are on the the mpls working group mailing list and
> aware of IPR that relates to this draft, the time to disclose this is
> now.
>>>
>>> /Loa
>>> (mpls wg co-chair)
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Huawei Technologies (consultant)     phone: [phone]
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]