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

[Eric Gray <[e-mail]>]

Loa,



                This would be acceptable to me, provided that the authors and the WG chairs make it a priority

to fix the IANA considerations section immediately after adoption, AND provided that the Chairs instruct

the draft authors to remove the instance where the draft is known to use a value already assigned in a

published RFC prior to reposting it as a WG draft.



                There is a big difference between telling a draft author to make changes in his or her draft while

it remains a private draft and telling them conditions under which it may be published as a working group

draft.



                As a working group, we certainly can say "we will adopt your private draft as a working group

draft, provided you make these specified  changes."  As a working group, we have a responsibility not

to ignore blatant errors in draft that will be a working group draft - no matter when we discover them.



                And, as I have already said, there are clearly cases where draft authors may inadvertently

include inappropriate abuse of IETF resources where it MUST be the case that working group chairs

and/or the IESG can direct either correction or removal of the draft - whatever its status at the time.



                By the way, just to avoid any confusion, I did not ask for a "perfect IANA section" - I asked only

that we not adopt an Internet Draft where the IANA section is clearly and specifically wrong.



--

Eric



-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]
Sent: Friday, June 07, 2013 10:00 AM
To: t.petch
Cc: Eric Gray; mpls; [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



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]<mailto:[e-mail]>>

> To: "Loa Andersson" <[e-mail]<mailto:[e-mail]>>

> Cc: <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;

> <[e-mail]<mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[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]<mailto:[e-mail]>

>>> Cc: [e-mail]<mailto:[e-mail]>;

>>> [e-mail]<mailto:[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]> [mailto:[e-mail]] On Behalf

>>> Of Loa Andersson

>>> Sent: Thursday, May 30, 2013 12:35 PM

>>> To: [e-mail]<mailto:[e-mail]>

>>> Cc: [e-mail]<mailto:[e-mail]>;

>>> [e-mail]<mailto:[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]<mailto:[e-mail]>

>> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>

>> Huawei Technologies (consultant)     phone: [phone]

>> _______________________________________________

>> mpls mailing list

>> [e-mail]<mailto:[e-mail]>

>> https://www.ietf.org/mailman/listinfo/mpls

>>

>

>



--





Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>

Huawei Technologies (consultant)     phone: [phone]